GNU bug report logs - #31546
27.0.50; macOS child frames with no mode-line mouse click problem

Previous Next

Full log

Message #50 received at 31546 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 31546 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>
Subject: Re: bug#31546: 27.0.50; macOS child frames with no mode-line mouse
 click problem
Date: Thu, 24 May 2018 09:19:44 +0200

>> Now I am confused.  Is this in any way related to the OP's report?
>> There the window below in the z-order gets scrolled but here you seem
>> to mean that a mouse click affects the window above in the z-order.
>
> I'm the OP. I'm sorry if I wasn't clear in the initial report. The problem
> is that the child frame (which appears on top of the parent frame) gets
> scrolled on click. In this gif, the visible frame is the child frame:
> https://dzwonsemrish7.cloudfront.net/items/3p2o232r1S333y1o1H3S/Screen%20Recording%202018-05-22%20at%2005.44%20AM.gif?v=b53e93c1

But I referred to Alan's response and it seems that he sees the
converse of what you observed.

>> I still don't understand which command gets executed in order to
>> scroll the parent frame's window.  That is, if with emacs -Q I click
>> anywhere on my single frame's only window's mode line, that window
>> never scrolls.  So please tell me how your window gets scrolled.
>
> I do not know what the command is that is scrolling the child frame. It
> does not appear in view-lossage.

And C-h k does not give any clue either?  Try putting "(ding)" into
'mouse-set-point' just before "(mouse-minibuffer-check)" and check
whether it rings when you click.  If it does, then please look into
'posn-set-point' which window gets selected.  I suppose it's the
parent frame's window which gets passed via EVENT to 'mouse-set-point'
so we will have to check why the child frame's window is not found
when constructing the event.  The corresponding GTK code to get the
right frame is already quite painful (see 'XTmouse_position') so I
wouldn't be surprised if macOS had similar problems.

>> If "the frame" is a child frame then this problem is pertinent to your
>> windowing system: With X or Windows child frames cannot be moved out
>> of their parent frames.
>
> This may be, but I'm at a loss as to how my windowing system would increase
> the height of an emacs window. It seems more likely that it is due to some
> bug in nsterm, but I have been wrong before.

Sorry.  I referred to your earlier

  I should say that even if I move the frame so that it's not over the parent
  frame the scrolling bug still happens.

so this was about moving the frame and not changing its height.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.