[wayland] SetWindowMouseTransparent is not working on popups.
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox93 | --- | verified |
People
(Reporter: emilio, Assigned: emilio)
References
(Blocks 2 open bugs)
Details
Attachments
(3 files)
STR:
- Go to https://www.mozilla.org/en-US/firefox/lockwise/ and click on the "Open in Firefox" button.
- See how the "passwords" button is highlighted.
- Try to click on it.
ER:
- Click goes through the panel and
about:loginsis opened.
AR:
- Nothing happens.
The panel has pointer-events: none, so we should be getting into aInitData->mMouseTransparent == true and call SetWindowMouseTransparent(true), but that doesn't seem to be working right. It works correctly on X11 though.
|
Assignee | |
Comment 1•3 years ago
|
||
Not sure if the culprit, but we get into this statement on X11, but not on Wayland.
|
|
Assignee | |
Comment 2•3 years ago
|
||
This makes sure we get an actual surface we can e.g. set input masks on:
|
||
Updated•3 years ago
|
|
||
Comment 3•3 years ago
|
||
We need to fix nsWindow::SetWindowMouseTransparent() for Wayland. We may need to clear input region for mShell too, not just for mContainer (mGdkWindow is derived from mContainer on Wayland but from mShell on X11).
|
|
Assignee | |
Comment 4•3 years ago
|
||
Yeah, I have a patch doing that but I think I hit a GDK bug when the widget is hidden and shown again. I can work around it but looking at building a standalone test-case first.
|
|
||
Updated•3 years ago
|
|
|
Assignee | |
Comment 5•3 years ago
|
||
Depends on D122584
|
|
Assignee | |
Comment 6•3 years ago
|
||
Depends on D122610
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/59fc1a56b230 Set input shape region in top-level window. r=stransky https://hg.mozilla.org/integration/autoland/rev/d17d7c9e7099 Drive-by cleanups. r=stransky https://hg.mozilla.org/integration/autoland/rev/c4297c666dec Work around a GTK bug where wayland input regions get lost. r=stransky
|
||
Comment 8•3 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/59fc1a56b230
https://hg.mozilla.org/mozilla-central/rev/d17d7c9e7099
https://hg.mozilla.org/mozilla-central/rev/c4297c666dec
|
||
Comment 9•3 years ago
|
||
The issue isn't completely fixed for me, I can still reproduce it sometimes.
Furthermore the patches introduced a new bug for me: When I click on the NoScript icon in the toolbar, I sometimes can't click on any of the items in the popup because the mouse focus is still on the webpage content (or whereever). The new issue seems to be related to this one, so I am not filing a new bug.
Emilio, can you still reproduce this bug?
|
|
||
Comment 10•3 years ago
|
||
Other extensions are also affected (clicking on items in the popup window doesn't work sometimes), e.g. uBlock Origin. "Sometimes" means in about 1/10 cases.
|
|
||
Comment 11•3 years ago
|
||
Clicking on items in the Privacy Badger popup window doesn't work almost always for me, so you can use that for reproducing.
|
|
Assignee | |
Comment 12•3 years ago
|
||
(In reply to Viktor Jägersküpper from comment #9)
The issue isn't completely fixed for me, I can still reproduce it sometimes.
I can't repro on Gnome fwiw.
Furthermore the patches introduced a new bug for me: When I click on the NoScript icon in the toolbar, I sometimes can't click on any of the items in the popup because the mouse focus is still on the webpage content (or whereever). The new issue seems to be related to this one, so I am not filing a new bug.
Hmm, how sure are you it is related to this bug? When you click on the popup does the click go to the website's content? Or is the click just lost? Either way I don't think this change should've affected any of the add-on popups, since those don't use pointer-events: none which is what triggers this code path.
Emilio, can you still reproduce this bug?
I haven't been able to (with the uBlock popup, on Gnome), but will try to repro with Privacy Badger and such. Will file a separate bug to investigate this.
|
|
||
Comment 13•3 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #12)
(In reply to Viktor Jägersküpper from comment #9)
Furthermore the patches introduced a new bug for me: When I click on the NoScript icon in the toolbar, I sometimes can't click on any of the items in the popup because the mouse focus is still on the webpage content (or whereever). The new issue seems to be related to this one, so I am not filing a new bug.
Hmm, how sure are you it is related to this bug? When you click on the popup does the click go to the website's content? Or is the click just lost? Either way I don't think this change should've affected any of the add-on popups, since those don't use
pointer-events: nonewhich is what triggers this code path.
I used mozregression and found this bug as the regressing change. Then I tried to reproduce this bug using your steps in the description and was successful surprisingly, so I tried again and it seemed fixed. After further tries I concluded that I can only reproduce it sometimes, but I don't know why. "Sometimes" is exactly what I observe for Noscript (and other extensions).
The fix for this bug and bug 1727709 comment 5 mention https://gitlab.gnome.org/GNOME/gtk/-/issues/4166, but I don't understand the technical side. If it helps, I can provide a log, just tell me what you need.
|
|
||
Comment 14•3 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #12)
When you click on the popup does the click go to the website's content? Or is the click just lost?
The click goes to the website's content indeed.
|
|
||
Comment 15•3 years ago
|
||
I have tested the autoland build with the second patch for bug 1727709 and I couldn't reproduce this issue any longer. Thanks!
|
||
Updated•3 years ago
|
|
||
Comment 16•3 years ago
|
||
Verified the fix as well with 93.0b7 on both Fedora34 and Win10.
Can confirm there is no issue with the functionality.
However, noticed that if the menu is scrollable the highlight doesn't follow the in-focus option but remains in the same X/Y position ending up on another option.
|
||
Comment 17•3 years ago
|
||
Removing qe+ flag based on comment 16 and comment 15. Thank you!
Description
•