[Thunderbird] With Linux, Dropdowns in Message Filter Rules don't close when clicking outside
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
thunderbird_esr115 | --- | unaffected |
thunderbird_esr128 | + | affected |
firefox-esr115 | --- | unaffected |
firefox-esr128 | --- | affected |
firefox128 | --- | wontfix |
firefox129 | --- | wontfix |
firefox130 | --- | wontfix |
firefox131 | --- | affected |
People
(Reporter: afranchuk, Assigned: stransky)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: leave-open, regression, triaged)
Attachments
(8 files, 4 obsolete files)
115.03 KB,
video/webm
|
Details | |
186.22 KB,
text/plain
|
Details | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
2.32 MB,
video/mp4
|
Details | |
1.63 MB,
video/mp4
|
Details | |
113.66 KB,
image/png
|
Details | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
This is likely a GUI implementation issue, maybe something to do with a window click event handler being overriden. The select box dropdowns in other windows close when clicking elsewhere in the window, however in the Filter Rules window all select box dropdowns (whether the "Getting New Mail: [select box]" or those in the filter rules/actions) never close. They only close when I move the mouse out of the window entirely.
I'm using X11 with XFCE4.
Comment 1•4 months ago
|
||
I see this too on Ubuntu with Gnome, on daily.
STR:
Tools | Filters
New...
In the rules, click open the rule to choose Subject or something else
Try to click outside.
Actual result: popup doesn't close. (It does close when clicking the popup itself.)
Expected: should close the popup when clicking elsewhere in the dialog.
This wasn't an issue in 115.
Alice, can we get a regression window?
Comment 2•4 months ago
•
|
||
Regression window:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=d11ce652f1e6fff06e8c4de52af63e483d4dd8b4&tochange=7cba2f9bbb38c538d77084a68414fe32d4bd8478
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=192e73e7c91313c09603efd1650931b917746bf4&tochange=3ddab45ce6bdbc0501b54ae64cbef202e8f92fb5
Suspect: Bug 1749174 - Enable wayland on supported environments by default on Nightly / Early Beta.
Regression window even if export MOZ_ENABLE_WAYLAND=0 :
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=07b121b1f4d828b99d6e00ab04c65c73ee141de4&tochange=c1975399a306d335b707ca9dc17d44e698c8e827
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a137631f73ce188671f50c5225295d64d427fec2&tochange=2ff68fa9f49916065f4ebb7a74c0940bf425f396
Suspect: Bug 1864382
Comment 3•3 months ago
|
||
Thanks Alice!
Martin, Emilio, any ideas?
Assignee | ||
Comment 4•3 months ago
|
||
Can you create a screencast of the issue?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Create_screenshot/screencast_for_a_bug_report
Thanks.
Comment 5•3 months ago
|
||
Kind of, since it's really about nothing happening on clicks outside the dropdown, the video doesn't show the issue too much.
Comment 6•3 months ago
|
||
Pretend that after opening the dropdown, I click around in the dialog (nothing happens: this is the bug).
Then i click inside the dropdown and it closes (like it should).
Updated•3 months ago
|
Reporter | ||
Comment 7•3 months ago
|
||
Yeah, mkmelin's screencast represents the issue as best as possible.
Comment 8•3 months ago
|
||
Yeah, so... We somehow don't seem to get those button presses at all from GTK. Same for other pointer events. You can see this with the cursor not changing when hovering over stuff.
If I make the code listen to mShell rather than mContainer, then it works:
diff --git a/widget/gtk/nsWindow.cpp b/widget/gtk/nsWindow.cpp
index 297149796986c..b007959812381 100644
--- a/widget/gtk/nsWindow.cpp
+++ b/widget/gtk/nsWindow.cpp
@@ -6332,23 +6332,23 @@ nsresult nsWindow::Create(nsIWidget* aParent, nsNativeWidget aNativeParent,
// and propagate up to the first widget that handles the events, so we
// need only connect on mShell, if it exists, to catch events on its
// window and windows of mContainer.
- g_signal_connect(mContainer, "enter-notify-event",
+ g_signal_connect(mShell, "enter-notify-event",
G_CALLBACK(enter_notify_event_cb), nullptr);
- g_signal_connect(mContainer, "leave-notify-event",
+ g_signal_connect(mShell, "leave-notify-event",
G_CALLBACK(leave_notify_event_cb), nullptr);
- g_signal_connect(mContainer, "motion-notify-event",
+ g_signal_connect(mShell, "motion-notify-event",
G_CALLBACK(motion_notify_event_cb), nullptr);
- g_signal_connect(mContainer, "button-press-event",
+ g_signal_connect(mShell, "button-press-event",
G_CALLBACK(button_press_event_cb), nullptr);
- g_signal_connect(mContainer, "button-release-event",
+ g_signal_connect(mShell, "button-release-event",
G_CALLBACK(button_release_event_cb), nullptr);
- g_signal_connect(mContainer, "scroll-event", G_CALLBACK(scroll_event_cb),
+ g_signal_connect(mShell, "scroll-event", G_CALLBACK(scroll_event_cb),
nullptr);
if (gtk_check_version(3, 18, 0) == nullptr) {
- g_signal_connect(mContainer, "event", G_CALLBACK(generic_event_cb),
+ g_signal_connect(mShell, "event", G_CALLBACK(generic_event_cb),
nullptr);
}
- g_signal_connect(mContainer, "touch-event", G_CALLBACK(touch_event_cb),
+ g_signal_connect(mShell, "touch-event", G_CALLBACK(touch_event_cb),
nullptr);
LOG(" nsWindow type %d %s\n", int(mWindowType),
Martin, do you know what might be going on / why gtk isn't sending us those events? Alternatively do you know of any issue if we just listen to events on mShell consistently?
Comment 9•3 months ago
|
||
An apparently related issue has been reported in bug 1902013. For that I came up with the same regression window as in comment 2 (second one) with Debian/XFCE, even though the reporter there uses 115.11.0.
Updated•3 months ago
|
Assignee | ||
Comment 10•3 months ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)
Martin, do you know what might be going on / why gtk isn't sending us those events? Alternatively do you know of any issue if we just listen to events on mShell consistently?
I'd say there's some event routing involved, perhaps the widget is created as input transparent or so? Is that reproducible with Thunderbird only? Do we see that in Firefox anywhere? I wonder how the popup is created and configured.
Can you please run TB with MOZ_LOG="Widget:5 WidgetPopup:5" env variable on terminal, reproduce it and attach the log here?
Thanks.
Assignee | ||
Updated•3 months ago
|
Reporter | ||
Comment 11•3 months ago
•
|
||
Here's the log. For your convenience, I interjected "STARTING" and "ENDED" lines around my interaction with the filter dialog dropdowns (though I include the entire log in case there's something else pertinent there). This captures the log of me opening the filters dialog, clicking "new", opening a single dropdown and then clicking around in the window (with the dropdown not closing and clicks doing nothing) until I move the mouse out of the window (at which point the dropdown closes).
Assignee | ||
Comment 12•3 months ago
|
||
Thanks. The whole sequence of menu creation look weird, I see there are many hidden menu popups opened/closed with the same parent window. I'd expect there's only two windows used - main dialog and the dropdown menu.
[Parent 24458: Main Thread]: D/Widget [7fe0b0b28c00]: nsWindow::Create
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b0b28c00]: mBounds: x:0 y:0 w:0 h:0
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b0b28c00]: nsWindow::Create() Popup
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b0b28c00]: nsWindow::Create() popup type Menu
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b0b28c00]: set parent window [7fe0ac469600] filtereditor
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b0b29100]: nsWindow::Create() Popup
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b0b29100]: nsWindow::Create() popup type Menu
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b0b29100]: set parent window [7fe0ac469600] filtereditor
[Parent 24458: Main Thread]: D/Widget [7fe0b392c600]: nsWindow::Create
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b392c600]: nsWindow::Create() Popup
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b392c600]: nsWindow::Create() popup type Menu
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b392c600]: set parent window [7fe0ac469600] filtereditor
[Parent 24458: Main Thread]: D/Widget [7fe0b3a3d200]: nsWindow::Create
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3a3d200]: mBounds: x:0 y:0 w:0 h:0
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3a3d200]: nsWindow::Create() Popup
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3a3d200]: nsWindow::Create() popup type Menu
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3a3d200]: set parent window [7fe0ac469600] filtereditor
[Parent 24458: Main Thread]: D/Widget [7fe0b0b29600]: nsWindow::Create
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b0b29600]: mBounds: x:0 y:0 w:0 h:0
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b0b29600]: nsWindow::Create() Popup
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b0b29600]: nsWindow::Create() popup type Menu
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b0b29600]: set parent window [7fe0ac469600] filtereditor
[Parent 24458: Main Thread]: D/Widget [7fe0b3a83e00]: nsWindow::Create
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3a83e00]: mBounds: x:0 y:0 w:0 h:0
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3a83e00]: nsWindow::Create() Popup
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3a83e00]: nsWindow::Create() popup type Menu
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3a83e00]: set parent window [7fe0ac469600] filtereditor
[Parent 24458: Main Thread]: D/Widget [7fe0b3a83400]: nsWindow::Create
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3a83400]: mBounds: x:0 y:0 w:0 h:0
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3a83400]: nsWindow::Create() Popup
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3a83400]: nsWindow::Create() popup type Menu
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3a83400]: set parent window [7fe0ac469600] filtereditor
[Parent 24458: Main Thread]: D/Widget [7fe0b3a83900]: nsWindow::Create
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3a83900]: mBounds: x:0 y:0 w:0 h:0
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3a83900]: nsWindow::Create() Popup
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3a83900]: nsWindow::Create() popup type Menu
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3a83900]: set parent window [7fe0ac469600] filtereditor
[Parent 24458: Main Thread]: D/Widget [7fe0b3fc1b00]: nsWindow::Create
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3fc1b00]: mBounds: x:0 y:0 w:0 h:0
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3fc1b00]: nsWindow::Create() Popup
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3fc1b00]: nsWindow::Create() popup type Menu
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3fc1b00]: set parent window [7fe0ac469600] filtereditor
arent 24458: Main Thread]: D/Widget [7fe0b3fc1100]: nsWindow::Create
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3fc1100]: mBounds: x:0 y:0 w:0 h:0
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3fc1100]: nsWindow::Create() Popup
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3fc1100]: nsWindow::Create() popup type Menu
[Parent 24458: Main Thread]: D/WidgetPopup [7fe0b3fc1100]: set parent window [7fe0ac469600] filtereditor
Assignee | ||
Comment 13•3 months ago
|
||
Magnus, can you point me where the filter dialog is located? Looks like TB is creating bogus popups which confuses the widget code.
Thanks.
Comment 14•3 months ago
|
||
Sure,
FilterEditorDialog: https://searchfox.org/comm-central/source/mailnews/search/content/FilterEditor.xhtml
The popup with the reported issue is created here: https://searchfox.org/comm-central/rev/a7f02aed18d176997ab8a762790a8b7d49d64aff/mailnews/search/content/searchWidgets.js#284 as part of a <search-operator> custom element - https://searchfox.org/comm-central/source/mailnews/search/content/searchWidgets.js#507
Comment 15•3 months ago
|
||
FilterEditorDialog is opened by code from another dialog, https://searchfox.org/comm-central/source/mail/base/content/FilterListDialog.xhtml
Assignee | ||
Updated•3 months ago
|
Assignee | ||
Updated•3 months ago
|
Assignee | ||
Updated•3 months ago
|
Assignee | ||
Updated•2 months ago
|
Reporter | ||
Comment 16•2 months ago
|
||
Does "Wayland" in the bug title imply that this is a wayland-only issue? I'm not running wayland.
Assignee | ||
Comment 17•2 months ago
|
||
(In reply to Alex Franchuk [:afranchuk] from comment #16)
Does "Wayland" in the bug title imply that this is a wayland-only issue? I'm not running wayland.
Yes, I removed it.
Assignee | ||
Comment 19•2 months ago
|
||
Fixed when reverted https://phabricator.services.mozilla.com/D193401 (but still broken on Wayland anyway).
We created popups without CSD and always painted to mShell before D193401 so the patch from comment 8 was active for popups.
Assignee | ||
Comment 21•2 months ago
|
||
We're hitting more bugs together here:
-
We create the popup as modal, it means underlying dialog (also modal) doesn't get mouse button events so we don't rollup the popup. We did that due to missing mouse grab (or its different architecture at Wayland so we can't use it).
-
If we get modal popup click outside, we receive such event on mShell and not on mContainer (why? Perhaps due to the modal state?)
-
If we connect event handlers to popup mShell (as we had before), due to bug (or feature) at GetFirstNSWindowForGDKWindow() we wrongly re-direct events from popup's mShell to parent dialog nsWindow so the popup is closed.
As due to missing pointer grab we need to emulate it with modal popup. I guess our only way is to detect outside click as mouse button event between leave - enter events, i.e. mouse button click when cursor is outside the popup.
Assignee | ||
Updated•2 months ago
|
Assignee | ||
Updated•2 months ago
|
Assignee | ||
Comment 22•2 months ago
|
||
Note that the bug was here before and changes at Bug 1864382 only reveals it.
Assignee | ||
Updated•2 months ago
|
Assignee | ||
Comment 23•2 months ago
|
||
Updated•2 months ago
|
Assignee | ||
Comment 24•2 months ago
|
||
Depends on D216911
Assignee | ||
Comment 25•2 months ago
|
||
- Move more widget events from mContainer to mShell. We generally want to listen on mShell and use mContainer
for GtkContainer related events only. - Set correct event masks for mShell/mContainer
Depends on D216912
Assignee | ||
Comment 26•2 months ago
|
||
Depends on D216913
Assignee | ||
Updated•2 months ago
|
Comment 27•2 months ago
|
||
Here's a screen recording of the developer toolbox with the changes. The inspector view should have a hover effect as the mouse rolls over it, but it doesn't. Clicking on things doesn't work either.
Assignee | ||
Comment 28•2 months ago
|
||
(In reply to Geoff Lankow (:darktrojan) from comment #27)
Created attachment 9413460 [details]
simplescreenrecorder-2024-07-18_20.53.40.mp4Here's a screen recording of the developer toolbox with the changes. The inspector view should have a hover effect as the mouse rolls over it, but it doesn't. Clicking on things doesn't work either.
As per discussion it's MINT/X11. Will try that, I don't see it on Gnome.
There's also a regression that system window titlebar doesn't receive mouse clicks on Wayland.
Assignee | ||
Comment 29•2 months ago
|
||
Depends on D216914
Comment 31•2 months ago
|
||
I can see what the problem might be, and it might something for a different bug. When the toolbox window is docked to the right hand side of the screen, the mouse events are happening as though the window was still in its previous position. In this recording you can see the mouse moving on the left side of the window, but things are happening on the right side of the window.
This doesn't seem to happen every time the window is docked, so I'm not sure what the trigger is. I was able to reproduce it fairly consistently in Firefox:
- Run
./mach run --jsdebugger
. - Dock the devtools window with Super + Right Arrow.
- Close Firefox.
- Repeat the same steps. (The first time is just to set the initial size of the window for the second time.)
(This was recorded before I updated my copy of the patches, but it still happens with the latest version.)
Assignee | ||
Comment 32•2 months ago
|
||
(In reply to Geoff Lankow (:darktrojan) from comment #31)
(This was recorded before I updated my copy of the patches, but it still happens with the latest version.)
Do I understand correctly that it doesn't depends of the patches here?
Thanks.
Comment 33•2 months ago
|
||
It only happens with the patches here.
Assignee | ||
Comment 34•2 months ago
|
||
Does D216914 make any difference here? Is the mouse motion bug less visible with it?
Thanks.
Updated•2 months ago
|
Assignee | ||
Comment 35•2 months ago
|
||
Assignee | ||
Comment 36•2 months ago
|
||
Geoff, please test with D217163 on top. It adds signal handlers to mContainer.
Comment 38•2 months ago
|
||
I've just noticed that pop-ups in the developer toolbox don't pop up in the right place. Same STR as before. Like before, they're where the window used to be.
Assignee | ||
Updated•2 months ago
|
Assignee | ||
Comment 39•1 month ago
|
||
Lets' track possible regressions in another bugs.
Comment 40•1 month ago
|
||
Pushed by stransky@redhat.com: https://hg.mozilla.org/integration/autoland/rev/a0c9c1dcb19c [Linux] Remove mRetryPointerGrab as it's unused r=emilio https://hg.mozilla.org/integration/autoland/rev/d6e1dbfd1002 [Linux] Remove GetFirstNSWindowForGDKWindow() as we don't use widget plugins r=emilio https://hg.mozilla.org/integration/autoland/rev/d300cc8b778e [Linux] Move some widget events from mContainer to mShell r=emilio https://hg.mozilla.org/integration/autoland/rev/e0e1f122e646 [Linux] Reformat widget event code r=emilio https://hg.mozilla.org/integration/autoland/rev/25389422d457 [Linux] Keep propagating relocated mShell events to child widgets r=emilio
Comment 41•1 month ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/a0c9c1dcb19c
https://hg.mozilla.org/mozilla-central/rev/d6e1dbfd1002
https://hg.mozilla.org/mozilla-central/rev/d300cc8b778e
https://hg.mozilla.org/mozilla-central/rev/e0e1f122e646
https://hg.mozilla.org/mozilla-central/rev/25389422d457
Comment 42•1 month ago
|
||
Backed out for causing multiple functional regressions on Linux.
Comment 43•1 month ago
|
||
Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/9b2d26f0ef7d
Assignee | ||
Updated•1 month ago
|
Assignee | ||
Updated•1 month ago
|
Comment 44•1 month ago
|
||
Pushed by stransky@redhat.com: https://hg.mozilla.org/integration/autoland/rev/3c1b5657b7f1 [Linux] Remove mRetryPointerGrab as it's unused r=emilio https://hg.mozilla.org/integration/autoland/rev/44257ccff494 [Linux] Remove GetFirstNSWindowForGDKWindow() as we don't use widget plugins r=emilio
Comment 45•1 month ago
|
||
bugherder |
Updated•25 days ago
|
Assignee | ||
Comment 46•11 days ago
|
||
Looks like the fix here is a part of the regression. When we register leave events to mShell we're getting leave events even for child popups which fixes the bug here but also brings new regression - but on X11 only.
Assignee | ||
Comment 47•10 days ago
|
||
A popup attached to a modal parent window doesn't get mouse events
from Gtk as they'are directed to the modal parent. This is usually solved
by pointer grab which that doesn't work on Wayland in our current
setup as it performs show and grab in one step.
We emulate it by setting popup as modal too but then patent
window doesn't get mouse events outside of popup (Bug 1899299).
we need to listen
Surprisingly attaching events handler to mShell fixes it
and we're getting events from both parent and popup windows.
Updated•10 days ago
|
Updated•10 days ago
|
Updated•10 days ago
|
Updated•10 days ago
|
Assignee | ||
Updated•10 days ago
|
Comment 48•4 days ago
|
||
Pushed by stransky@redhat.com: https://hg.mozilla.org/integration/autoland/rev/0727ff9372dc [Linux] Listen mouse events on mShell for modal popups r=emilio
Comment 49•3 days ago
|
||
bugherder |
Description
•