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


(Core :: Widget: Gtk, defect)




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


(Reporter: jan, Assigned: emilio)




(Keywords: nightly-community, regression)


(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
  • MOZ_GTK_TITLEBAR_DECORATION=none mozregression --launch 2021-12-10 --pref gfx.x11-egl.force-disabled: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, I found bug 1745582. It has sister regressions.
Flags: needinfo?(emilio)

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

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
Component: Bookmarks & History → Widget: Gtk
Product: Firefox → Core
Pushed by
Update nsWindow::mMouseTransparent in nsWindow::SetMouseTransparent. r=stransky
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 97 Branch

This issue was also mentioned in; I can confirm the reproduction AND this fix in Nightly v97.0a1 from 2021-12-14.

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