1046243 - On OSX 10.9, mouse scrolling scrolls the wrong browser window

Status: NEW

(Core :: Widget: Cocoa, defect)

Description

[Matthew Francis]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140716183446

Steps to reproduce:

1. Open two Firefox browser windows
2. Switch the focus to another application
3. Using the mouse, without focusing Firefox, scroll up and down with the mouse pointer positioned over each of the Firefox windows



Actual results:

Regardless of which browser window the mouse is actually over, only one of the two windows is scrolled.

(On a few occasions, I have observed that scrolling in a second window will work after scrolling in the first window, but will then get stuck in the second window. The first window is then again unable to be scrolled until it is focused)


Expected results:

The browser window that the mouse is actually over should be scrolled. If Firefox is the focused application, this works as expected, and even a background browser window can be scrolled using the mouse without needing to focus it first

This was observed on OSX 10.9.4, on a 2011 era iMac with two external screens connected; "System Preferences -> Mission Control -> Displays have separate Spaces" is enabled. The issue does not depend on which screen the windows are on, or whether they are on separate screens

Comment 1

[Matthew Francis]

Attachment: A short screen capture video which shows the issue

Please see the attached video. Contrary to what I initially thought, this can occur even if FF is the focused application

Comment 2

[:Gijs (he/him)]

I can reproduce this (without any external screens). Markus, any idea what would be causing this?

Comment 3

[Steven Michaud [:smichaud] (Retired)]

I think this is intentional.  In any case other Mac programs behave similarly, for example Safari.

Comment 4

[Matthew Francis]

(In reply to Steven Michaud from comment #3)
> I think this is intentional.  In any case other Mac programs behave
> similarly, for example Safari.

Safari reliably exhibits the correct behaviour for OSX, which is that the window under the cursor is scrolled regardless of the app or window that is focused.
As shown by the attached video, the scrolling in FF currently appears to be confused, and does not obey a consistent rule for which window is scrolled.

To summarise the content of the video in text form:
There are two overlapping FF windows. Initially, FF is not the focused application
1. Without focusing FF, the top window is mouse scrolled. This works as expected
2. Without focusing FF, the bottom window is mouse scrolled. This works as expected
3. Without focusing FF, the top window is mouse scrolled again. This incorrectly results in the bottom window being scrolled
4. The top window is focused with a mouse click, and mouse scrolled again. This incorrectly results in the bottom window being scrolled

If only one window were actually scrolled in the above sequence, it would at least be consistent - if with the wrong operating system. The observed results aren't currently consistent with anything

Comment 5

[Markus Stange [:mstange]]

(In reply to :Gijs Kruitbosch from comment #2)
> Markus, any idea what would be causing this?

Maybe WheelTransaction holds on to the scrolled view for too long because it doesn't observe any mouse move events. That's what bug 455679 is about, and this sounds similar.

Comment 6

[André Reinald]

Recalling my work on bug 868648, WheelTransaction indeed keeps track of the view to be scrolled, and that's on purpose, because we don't want the scroll focus to change if, at a moment, a scrollable sub-view appears under the pointer while the super-view is scrolled.

If I remember well, WheelTransaction is reset when a mouse move event is received. This may not happen when Firefox is in the background.

Though, the WheelTransaction is reset after a timeout. So if STR are performed with more than about 1.5 seconds between them, the bug doesn't occur.

Masayuki Nakano was my reviewer on bug 868648 and he may be a good adviser on this one.

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to André Reinald from comment #6)
> If I remember well, WheelTransaction is reset when a mouse move event is
> received.

Yes.

> This may not happen when Firefox is in the background.

Could be.

I guess that if receiving wheel events in different ESM, WheelTransaction::OnEvent() should take a pointer to ESM in its argument and store it as weak reference. Then, OnEvent() should compare the old ESM and coming ESM if the event is NS_WHEEL_*, NS_MOUSE_MOVE or NS_DRAG_MOVE.

Another possibility is, NS_MOUSE_MOVE isn't fired on deactive window on Mac. If so, we need to check the cursor moving in OnEvent()'s NS_WHEEL_WHEEL case.

http://mxr.mozilla.org/mozilla-central/source/dom/events/WheelHandlingHelper.cpp#163

Comment 8

[Harvey Chapman]

In case bugzilla doesn't automatically cross-link bugs, I just entered a scrolling bug on OSX that might be related to this one: https://bugzilla.mozilla.org/show_bug.cgi?id=1102945

It has to do with scrolling an inactive Firefox window and realizing that there's a 1-2 second timer in effect after scrolling in Firefox when moving between a scrolled text area and the page that contains it. Crossing a text area scroll bar negates the timeout.