456164 - Mouse wheel scrolls both tree and column picker menu

Status: RESOLVED FIXED

(Toolkit :: UI Widgets, defect)

Description

[Francis Gastellu]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.2) Gecko/2008090514 Firefox/3.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.2) Gecko/2008090514 Firefox/3.0.2

Scrolling a tree columnpicker menuitems using the mouse wheel also scrolls the parent tree content.

Reproducible: Always

Steps to Reproduce:
1. Open a window with a tree containing a column picker (eg, DOM inspector)
2. Make sure the tree has enough content so that the vertical scrollbar shows up
3. Click the column picker button
4. Use the mouse wheel to scroll down
Actual Results:  
The tree scrolls.

Expected Results:  
The tree does not scroll. 

When the tree column picker has more items than can be shown, the mouse wheel can be used to scroll through the items, but the DOMMouseScroll event is captured by the underlying tree (tree.xml:621) before the columnpicker has had a chance to issue stopPropagation() (scrollbox.xml:363) because the tree uses phase="capturing".

It does not appear that the bug is a problem in default installs of Firefox because nothing seems to be using the columnpicker, or do so with enough items that the user may need to use the mouse wheel on the menu. Extensions may run into it though, as well as XR applications (the bug is quite prominent in Songbird, for instance).

Removing phase="capturing" from the tree binding solves the problem, but there may actually be a reason why it is using the capture phase that we do not know about, and that would make this particular fix the wrong way to go. Additional information about this would be welcome.

Comment 1

[Francis Gastellu]

Attachment: Test case

Comment 2

[Francis Gastellu]

Attachment: proposed patch

Comment 3

[[e-mail]]

Comment on attachment 339857 [details] [diff] [review]
proposed patch

Bug 108757 made it that way for no particular reason, and I carried it over when I converted it to <handler> again for no particular reason ;-)

Comment 4

[Serge Gautherie (:sgautherie)]

Comment on attachment 339857 [details] [diff] [review]
proposed patch

Please, could you attach an unbitrotted and Hg patch ?

Comment 5

[Stephen Lau]

Attachment: Francis's patch updated for tip and hg export'd

Serge - here is Francis's patch updated for tip, exported from hg.

Comment 6

[Stephen Lau]

Attachment: Fix author/username on patch

Updated to fix the user/author to be Francis, not me.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Pushed 51aa90287267 to trunk