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

[martin rudalics <rudalics@gmx.at>]

 >> 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