Closed Bug 849544 Opened 7 years ago Closed 6 years ago

Don't consume mouse scroll events outside arrow panels on Linux

Categories

(Core :: Widget: Gtk, defect)

All
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla28
Tracking Status
firefox28 --- fixed

People

(Reporter: fryn, Assigned: enndeakin)

References

(Blocks 1 open bug)

Details

(Whiteboard: [qa-])

Attachments

(2 files)

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.
attachment 786608 [details] looks like a different bug.
Duplicate of this bug: 935460
Attached patch mousewheelgtkSplinter Review
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Attachment #8339371 - Flags: review?(karlt)
Attachment #8339371 - Flags: review?(karlt)
Is there something else here that needs to be done besides bug 935460?
Blocks: 943949
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.
https://hg.mozilla.org/mozilla-central/rev/27b8fa302368
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Flags: in-testsuite?
Whiteboard: [qa-]
Depends on: 1265308
You need to log in before you can comment on or make changes to this bug.