If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Mouse wheel scrolls both tree and column picker menu

RESOLVED FIXED

Status

()

Toolkit
XUL Widgets
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: Francis Gastellu, Assigned: Francis Gastellu)

Tracking

Trunk
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Assignee)

Description

9 years ago
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.
(Assignee)

Updated

9 years ago
Component: General → XUL Widgets
Product: Firefox → Toolkit
Version: unspecified → Trunk
(Assignee)

Comment 1

9 years ago
Created attachment 339556 [details]
Test case
(Assignee)

Comment 2

9 years ago
Created attachment 339857 [details] [diff] [review]
proposed patch

Comment 3

9 years ago
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 ;-)

Updated

9 years ago
Attachment #339857 - Flags: review+

Updated

9 years ago
Assignee: nobody → lonedfx
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: checkin-needed
Comment on attachment 339857 [details] [diff] [review]
proposed patch

Please, could you attach an unbitrotted and Hg patch ?
Attachment #339857 - Attachment is obsolete: true
Flags: in-testsuite?
Keywords: checkin-needed

Comment 5

9 years ago
Created attachment 352855 [details] [diff] [review]
Francis's patch updated for tip and hg export'd

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

Comment 6

9 years ago
Created attachment 352856 [details] [diff] [review]
Fix author/username on patch

Updated to fix the user/author to be Francis, not me.
Attachment #352855 - Attachment is obsolete: true
Keywords: checkin-needed
QA Contact: general → xul.widgets
Pushed 51aa90287267 to trunk
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Blocks: 357052
You need to log in before you can comment on or make changes to this bug.