Closed Bug 1814291 Opened 1 year ago Closed 1 year ago

Popups are dismissed when the pointer leaves them under FVWM


(Core :: Widget: Gtk, defect)




111 Branch
Tracking Status
firefox-esr102 --- unaffected
firefox109 --- unaffected
firefox110 --- fixed
firefox111 --- fixed


(Reporter: jld, Assigned: jld)




(Keywords: regression)


(1 file)

Related to bug 1807482, but less severe: Under FVWM (with focus-follows-mouse), it is possible to use popup elements — it's possible to click and then move the pointer into the popup, but it will be dismissed immediately if the pointer ever leaves the popup even for a moment, even if it's still over the main window. It's still possible to use them, but the experience can be frustrating.

This doesn't happen with either Openbox or XFWM4. I tried investigating a little using karlt's test program from bug 631518 comment #33; it looks like fvwm is setting the focus to itself and then back to Firefox, and it's deliberately trying to create a focus leave/enter event because it thinks this is a case where there ought to be one, possibly because GTK is setting input focus to a 1x1 subwindow of the main window (this seems odd to me but it is what it is), or maybe just because it doesn't recognize the popup as related to the main window (even though in theory it does know about WM_TRANSIENT_FOR hints and at least some of NetWM).

In any case, this is another window-manager-specific quirk that can be worked around by turning pointer grabbing back on, so I think it makes sense to do that by default if we detect FVWM (rather than requiring affected users to know about the widget.gtk.grab-pointer pref).

Without pointer grabs, it's possible to move the pointer into a popup
element and use it, but if the pointer leaves even for a moment, the
popup will be dismissed. This seems to be a FVWM-specific quirk
(see bug for more info); other WMs with focus-follows-mouse policies
(Openbox, XFWM4) handle focus changes differently and aren't affected.
To avoid that, this patch turns pointer grabbing back on if we detect

Set release status flags based on info from the regressing bug 1798131

Pushed by
Grab the pointer for popups under FVWM. r=emilio
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 111 Branch

The patch landed in nightly and beta is affected.
:jld, is this bug important enough to require an uplift?

  • If yes, please nominate the patch for beta approval.
  • If no, please set status-firefox110 to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(jld)

Comment on attachment 9315279 [details]
Bug 1814291 - Grab the pointer for popups under FVWM.

Beta/Release Uplift Approval Request

  • User impact if declined: Linux (and *BSD etc.) users using FVWM will have a worse experience dealing with menus or popup/dropdown UI elements — they will disappear if the pointer moves briefly outside them, when this is not the case on other window managers or OSes.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This patch only takes effect if FVWM is in use; other users shouldn't be affected. (It just adds a condition for whether to use the workaround code landed in an earlier bug.)
  • String changes made/needed: none
  • Is Android affected?: No
Flags: needinfo?(jld)
Attachment #9315279 - Flags: approval-mozilla-beta?

Comment on attachment 9315279 [details]
Bug 1814291 - Grab the pointer for popups under FVWM.

I am taking the patch to the beta branch as this fixes a 110 regression and it is limited to a very small subset of our users should a regression happen, thanks..

Attachment #9315279 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Duplicate of this bug: 1831433
See Also: → 1831433
See Also: 1831433
You need to log in before you can comment on or make changes to this bug.