734937 - Mousewheel doesn't scroll over XUL trees

Status: NEW

(Toolkit :: UI Widgets, defect)

Description

[ryan.brothers]

Attachment: test_scroll.xul

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Build ID: 20120215223356

Steps to reproduce:

Starting with Firefox 7 and later including Firefox 10 on Windows, I have observed the following behavior with the attached xul file test_scroll.xul where the mousewheel doesn't scroll over XUL trees correctly.


Actual results:

If you use the mousewheel to scroll down the page, the scrolling will stop once the mouse cursor reaches the first tree.  You have to move the mouse cursor off of the tree and then the mousewheel will continue to scroll down the page.

Likewise, once the mouse cursor reaches the 2nd tree, the scrolling scrolls the tree to the end, but then stops.  You have to again move the mouse cursor off of the tree to continue the mousewheel scrolling down the page as a whole.

This behavior is different compared to Firefox 6 and earlier.  In those versions, the outer page continues to scroll regardless of the mouse cursor position and subject to the 2 about:config options:

- mousewheel.transaction.ignoremovedelay = 100
- mousewheel.transaction.timeout = 1500



Expected results:

This expected behavior is documented on https://wiki.mozilla.org/Gecko:Mouse_Wheel_Scrolling which states that each scrolling action is repeated recursively for the ancestor frame, or <tree> in this case.

I confirmed that the expected behavior does occur on a html page with an iframe such as the attached html file test_scroll.html.  I can use the mousewheel to scroll the entire page skipping the iframe as long as I don't pause my scrolling on the iframe.

I believe the problem is specifically related to XUL trees in some form.  The scrolling focus is immediately shifting to the tree as soon as the mouse is over it, ignoring the above 2 about:config settings.

Can you please investigate and restore the earlier functionality where the scrolling would continue for the entire screen even if the mouse cursor is over a tree?

Comment 1

[ryan.brothers]

Attachment: test_scroll.html

Comment 2

[Alice0775 White]

Regression window(m-c)
Works:
http://hg.mozilla.org/mozilla-central/rev/7898841a922a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110630 Firefox/7.0a1 ID:20110702004346
Fails:
http://hg.mozilla.org/mozilla-central/rev/7b44ed36faf3
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110702 Firefox/7.0a1 ID:20110702022656
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7898841a922a&tochange=7b44ed36faf3



Regression window(m-i)
Works:
http://hg.mozilla.org/integration/mozilla-inbound/rev/e5de7146ac19
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110701 Firefox/7.0a1 ID:20110701164146
Fails:
http://hg.mozilla.org/integration/mozilla-inbound/rev/b48ff0b329b6
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110701 Firefox/7.0a1 ID:20110701204306
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e5de7146ac19&tochange=b48ff0b329b6

Triggered by:
ae8e81569712	Neil Deakin — Bug 655004, cancel mouse scroll event and key events for grid datepicker and trees, prevents scroll events from bubbling up in tests, r=neil

Comment 3

[[e-mail]]

But the previous behaviour would have stopped you from scrolling the second XUL tree, so that's not exactly ideal...

Comment 4

[Alice0775 White]

(In reply to [e-mail] from comment #3)
> But the previous behaviour would have stopped you from scrolling the second
> XUL tree, so that's not exactly ideal...


Umm, in my Firefox6 clean profile,
Scrolling does NOT stop 1st and 2ND tree both.
http://hg.mozilla.org/releases/mozilla-release/rev/5b6c2f8ff6da
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2 ID:20110902133214

Comment 5

[Markus Stange [:mstange]]

The tree could check whether there's anything to scroll, and stop consuming scroll events once you've reached the end.

Comment 6

[ryan.brothers]

How does the logic work for the html/iframe case that I attached above in test_scroll.html?  If I use the mousewheel to scroll quickly down that page, the iframe will not scroll as long as I don't pause my scrolling while the cursor is over the iframe.  If I do pause my scrolling, then the iframe will start to scroll.  I believe it's subject to the mousewheel.transaction.ignoremovedelay and mousewheel.transaction.timeout.  Could the XUL tree follow similar logic?

Comment 7

[[e-mail]]

HTML scrolling is performed by the nsMouseWheelTransaction class in nsEventStateManager.cpp, however I can't see an obvious integration point.

Comment 8

[ryan.brothers]

Thanks, is it possible then to restore the pre-Firefox 7 behavior where the entire page scrolls and does not stop for either of the 2 trees in the example file as Alice mentioned above?

Comment 9

[[e-mail]]

As I mentioned in comment 3, that would be worse than the current behaviour.
Comment 5 describes an improved behaviour, but it needs to be implemented.

Comment 10

[ryan.brothers]

The behavior in Firefox 6 and earlier is the correct behavior to me - you can scroll the entire page using the mousewheel.  You cannot scroll the entire page in Firefox 7 and later.  Instead, you get stuck scrolling after the 1st tree and the page appears to freeze (at least to a non-technical user) as once the mouse cursor hits the 1st tree, scrolling up and down on the page no longer works using the mousewheel.

Comment 11

[[e-mail]]

That's because you're focused on scrolling the page. For someone wanting to scroll the tree, Firefox 6's behaviour would be wrong. While the current behaviour isn't perfect, it is less worse than the previous behaviour.

Comment 12

[ryan.brothers]

Yes, I understand if you want to scroll the tree only.  I don't know of the internal changes involved, but that is why I was thinking if the functionality could match the html/iframe example in test_scroll.html.  In that file, if I start the mousewheel on the page, the page scrolls.  If I start the mousewheel in the iframe, the iframe scrolls.  That matches the documentation on https://wiki.mozilla.org/Gecko:Mouse_Wheel_Scrolling under the section "Gecko honors the mouse cursor position".

Comment 13

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

Looks like bug 655004 did change the behavior for automated tests rather than user experience... The bug's description is "some keyboard events for datetimepicker, trees and listboxes can bubble up to the scroll the main content when they shouldn't". So, "when" is important for these issues. But the patch changed the behavior "always"...

Comment 14

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

(In reply to [e-mail] from comment #11)
> That's because you're focused on scrolling the page. For someone wanting to
> scroll the tree, Firefox 6's behaviour would be wrong. While the current
> behaviour isn't perfect, it is less worse than the previous behaviour.

Which is the focused element for mouse wheel scrolling is very difficult issue. We have assumed that we can detect it by the transaction which is managed in very short time for humans, not for automated tests.

Looks like there were no people complaining about the old behavior. So, I think that we should back out the change only from DOMMouseScroll and MozMousePixelScroll handlers of datepicker.xul and tree.xul. And it should be done in the iframe of the test harness.

Comment 15

[ryan.brothers]

As Masayuki wrote above, can the pre-Firefox 7 behavior please be restored?  This issue is causing significant user experience issues in my XUL application - in my example above, users are trying to scroll with the mousewheel and they are getting stuck scrolling after the 1st tree.  The page appears to freeze (at least to a non-technical user) as once the mouse cursor hits the 1st tree, scrolling up and down on the page no longer works using the mousewheel.

The expected behavior is:

- if I start the mousewheel on the page, the page scrolls
- if I start the mousewheel on a tree, the tree scrolls.

Right now, that is not happening.  The expected behavior matches the documentation on https://wiki.mozilla.org/Gecko:Mouse_Wheel_Scrolling under the section "Gecko honors the mouse cursor position".