Closed Bug 849544 Opened 7 years ago Closed 6 years ago
Don't consume mouse scroll events outside arrow panels on Linux
This is a followup to bug 631473, in which we fixed the issue for OS X. Currently, we consume mouse scroll events outside open arrow panels on Linux, probably because we treat arrow panels like menu popups in some parts of their implementation. However, unlike button menus or context menus, arrow panels were not meant to be modal, especially since they are often opened without direct user input. Therefore, the outside mouse scroll events should not be consumed.
Note that on Linux the panels completely break the focus of whole X session. When a panel is open you cannot focus another application by pointing at its window.
(In reply to Frank Yan (:fryn) from comment #0) > However, unlike button menus or context menus, > arrow panels were not meant to be modal, especially since they are often > opened without direct user input. Therefore, the outside mouse scroll events > should not be consumed. (In reply to Michal 'hramrach' Suchanek from comment #1) > When a panel is open you cannot focus another application by pointing at its > window. Yes, same issues with location bar dropdown, etc. This probably depends more on whether Gecko is going to consume the rollup event, than on whether the panel has an arrow. I expect Gecko should not grab the pointer when it is not going to consume the rollup event. That might be easier than using GrabModeAsync.
The difference between the two types of popups was once available in CaptureRollupEvents through a parameter. That has been removed in bug 701760. Perhaps it is possible to reinstate that. That may be better than a ConsumeOutsideClicks/Motion/Scroll() method on nsIRollupListener because it makes it clear that CaptureRollupEvents() needs to be called again if the consume behavior for outside clicks changes.
I don't know if this is the same problem.
Duplicate of this bug: 906390
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Is there something else here that needs to be done besides bug 935460?
The patch addresses the issue presented here as the primary symptom, so I've opened bug 943949 for the remaining issues, and this bug can be closed.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
You need to log in before you can comment on or make changes to this bug.