Closed Bug 1745551 Opened 1 year ago Closed 1 year ago

[Linux non-wayland] Clicks in the "add/edit bookmark" panel's bookmark location dropdown on the address bar's star button don't get registered

Categories

(Core :: Widget: Gtk, defect)

x86_64
Linux
defect

Tracking

()

VERIFIED FIXED
97 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox95 --- unaffected
firefox96 --- unaffected
firefox97 --- verified

People

(Reporter: jan, Assigned: emilio)

References

(Regression)

Details

(Keywords: nightly-community, regression)

Attachments

(2 files)

Attached video video.webm
No description provided.

Screencast: Gnome Xwayland, Debian Testing
mozregression --launch 2021-12-10

The problem does not seem to occur with:
MOZ_ENABLE_WAYLAND=1 mozregression --launch 2021-12-10

I can reproduce the issue in Nightly97.0a1 Ubuntu20.04 no wayland.

Flags: needinfo?(gijskruitbosch+bugs)

Given this is platform-specific (doesn't reproduce on macOS or Windows, and doesn't reproduce with wayland), the clicks on the select dropdown in the screencast seem to be going to the wrong widget, but both the select dropdown and parent panel stay open, I don't see how that could be directly related to the patch in bug 1714846, which is x-platform and doesn't change the display type of popups while they're open - the other regressions are all caused by the containing panel/popup closing immediately and becoming display: none, and that breaking click/command handling. Maybe Emilio has a better idea of what's going on here, but from a frontend perspective I have no idea why the clicks wouldn't register in the right popup here - that seems like a widget/layout question.

Darkspirit, are you sure about the regression range? There've been some changes to how select/menulist works recently and off-hand that seems like a more plausible cause for issues here.

Component: Downloads Panel → Bookmarks & History
Flags: needinfo?(jan)
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(emilio)
Summary: Can't change bookmark location → [Linux non-wayland] Clicks in the "add/edit bookmark" panel's bookmark location dropdown on the address bar's star button don't get registered

Thanks Alice. Well, I guess that answers that - though I'm still lost as to how the change in question produced this bug.

Flags: needinfo?(jan)
See Also: → 1745582

I took a widget log and there's a SetWindowMouseTransparent(1) call. Will try to dig on where that comes from.

(In reply to :Gijs from comment #3)

Darkspirit, are you sure about the regression range?

Yes, mozregression --good 2021-12-01 --bad 2021-12-10 points to bug 1714846.

Also reproducible with:

  • mozregression --launch 2021-12-10 --pref gfx.x11-egl.force-disabled:true
  • mozregression --launch 2021-12-10 --pref gfx.x11-egl.force-disabled:true gfx.webrender.software:true
  • MOZ_GTK_TITLEBAR_DECORATION=none mozregression --launch 2021-12-10 --pref gfx.x11-egl.force-disabled:true gfx.webrender.software:true gfx.webrender.allow-partial-present-buffer-age:false gfx.webrender.max-partial-present-rects:0 layout.animation.prerender.partial:false
    • But when I added gfx.webrender.software.opengl:true, I found bug 1745582. It has sister regressions.
Flags: needinfo?(emilio)

This doesn't repro on Wayland because of this workaround:

https://searchfox.org/mozilla-central/rev/5909d5b7f3e247dddff8229e9499db017eb438e2/layout/xul/nsMenuPopupFrame.cpp#399

But basically if we get initialized with pointer-events: none, then
update the style and then show and configure the gtk window, we
configure the wrong transparency.

Assignee: nobody → emilio
Status: NEW → ASSIGNED
Status: ASSIGNED → NEW
Component: Bookmarks & History → Widget: Gtk
Product: Firefox → Core
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0e22fdb77362
Update nsWindow::mMouseTransparent in nsWindow::SetMouseTransparent. r=stransky
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 97 Branch

This issue was also mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1739142#c16; I can confirm the reproduction AND this fix in Nightly v97.0a1 from 2021-12-14.

Status: RESOLVED → VERIFIED
See Also: 1745582
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.