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

[Aaron Jensen]

On Sun, May 27, 2018 at 10:52 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
> I'm guessing this is somehow used to determine whether or not to scroll
the
> clicked location into view. The calculation is wrong if there is no
> mode-line because it subtracts 1 unnecessarily. My patch adds to the
> condition a check for the mode line format and does not subtract 1 if that
> is nil.

> Actually, looking at the code that's exactly what's happening:

> (cond
>                     ((null mouse-row))
>                     ((< mouse-row top)
>                      (mouse-scroll-subr start-window (- mouse-row top)
>                                         nil start-point))
>                     ((>= mouse-row bottom)
>                      (mouse-scroll-subr start-window (1+ (- mouse-row
bottom))
>                                         nil start-point)))

> If the location clicked is >= to the bottom (which is miscalculated
without
> my patch when there is no mode-line and it is >= in the case of a partial
> line visibility) then the window is scrolled, explicitly. So, that's the
> problem afaict.

One more clue: On a frame that doesn't accept focus on a mac, a single
click results in a mouse-movement getting fired immediately after the
down-mouse-1. A single click on a normal frame does not do this. This is
why this issue doesn't repro on a frame that accepts focus. Something about
how the non-focusable frames are causes them to get mouse moves immediately
after a click. This means that the transient map created in
mouse-drag-track immediately gets invoked with a mouse-movement, which is
what triggers the scroll. As mentioned earlier in the thread, this is only
true if the mouse has moved since the last click. That means if you click
twice in row, only the first click will get a mouse-movement fired after
it. If you then move the mouse and click again, it'll fire the down-mouse-1
then the mouse-movement again.

Perhaps someone who understands the way that mouse tracking works on mac
would know why a frame that doesn't accept focus behaves differently? It's
as if the non-focusable window only gets notified of a mouse's new position
whenever a click happens, so every click is as if the click happened and
then the mouse moved to that position.