After a while the popup menus in Firefox stop coming up
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
People
(Reporter: boris, Unassigned)
References
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0
Steps to reproduce:
Right clicking a tab, the address bar, a toolbar button or the page itself should bring up various popup menus in Firefox.
Actual results:
After a while (this is important, it does not happen right away) popup menus in Firefox stop working. If I then right click anywhere in Firefox (address bar, tabs, the content of a page, toolbar buttons) there is a visible flash of a popup menu but it immediately disappears.
After repeatedly trying to right click, the flash also disappears.
Note that the symptoms sound very similar to https://bugzilla.mozilla.org/show_bug.cgi?id=552180
I did actually go through the troubleshooting page and tried to reproduce this in Safe Mode and with a different profile. The issue remains and is reproducible.
I don't know how long it takes to stop working but would guess it is somewhere between half an hour and one of hour of starting Firefox.
Restarting Firefox fixes the issue, but is really inconvenient.
I am willing to enable additional logging or gather other diagnostics to figure this out.
I am running on a current ArchLinux installation ( 5.12.13-arch1-2 ). Packages are up to date.
Expected results:
The popup menu shouldn't stop working after a while.
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Toolbars and Customization' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 2•3 years ago
|
||
Hi,
I wasn't able to reproduce the issue on my end.
Could you please check if this also occurs using troubleshoot mode? Here is a link that can help:
https://support.mozilla.org/en-US/kb/diagnose-firefox-issues-using-troubleshoot-mode?redirectslug=Safe+Mode&redirectlocale=en-US#w_how-to-start-firefox-in-4troubleshoot-modesf5safe-modesf
Thanks!
Yes it occurs for me in Troubleshooting mode. I also tried a new profile and it also occurs there.
I expect that this is hard to ad hoc reproduce and with the limited information I can provide it is hard to determine a cause for this. But I was hoping there are ways to enable more logging in Firefox to figure out what is going on. Note that no other programs that I use exhibit this behaviour on my Linux installation.
In fact I can log into another user on my Linux machine and then the problem also does not occur (same Linux, same window manager).
|
|
||
Updated•3 years ago
|
|
||
Comment 4•3 years ago
|
||
(In reply to aggregat4 from comment #3)
Yes it occurs for me in Troubleshooting mode. I also tried a new profile and it also occurs there.
I expect that this is hard to ad hoc reproduce and with the limited information I can provide it is hard to determine a cause for this. But I was hoping there are ways to enable more logging in Firefox to figure out what is going on. Note that no other programs that I use exhibit this behaviour on my Linux installation.
In fact I can log into another user on my Linux machine and then the problem also does not occur (same Linux, same window manager).
Huh, this is all very mysterious.
When the popup menus break, does opening new Firefox windows still work?
Are you using wayland or gtk? (If you don't know, can you go to about:support, click the button there to "copy raw data to clipboard" and then paste it at https://bugzilla.mozilla.org/attachment.cgi?bugid=1719175&action=enter to attach it to this bug?)
And what window manager?
In terms of logging / error messages, are there errors in the browser console (open with ctrl-shift-j; this is different from the normal devtools console!) ?
At the moment it's hard to know what level the problem is happening at, and therefore what to log, but it tentatively sounds like it'd be widget-related. Karl or Martin, can you advise on what logging we could use to see what is happening with menupopups?
I do realize and apologize for the hard to reproduce nature of this thing. I have been trying everything I could think off, but still run into the issue and this was my way to try a last ditch approach to resolve this.
To your questions:
- When the popup menus break I can still open new windows and tabs using keyboard shortcuts. All other menus (the actual menus from the menbar (File menu for example), the firefox hamburger menu, etc) automatically disappear.
- This is XFCE 4.16, window manager is xfwm4, I am on X11, not Wayland
- I attached the output of about:support to this issue
- The browser console (didn't know this existed!) does have errors. I am currently in the error state (popups don't work) and have the following entries:
WebExtensions: reset-default-search: starting. api.js:183
WebExtensions: reset-default-search: has already ran once and saw panel, exit. api.js:210
Tried to send a 'target-destroyed-form' event on an already destroyed actor 'watcher' 2 Actor.js:58:15
TypeError: fxaButton is null
2 BrowserGlue.jsm:4157:17
Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. background.js:2
Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. background.js:2
Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. background.js:2
Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. background.js:2
Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. background.js:2
TypeError: fxaButton is null
3 BrowserGlue.jsm:4157:17
WebGL context was lost. 2 Troubleshoot.jsm:692:17
WebGL context was lost. 2 Troubleshoot.jsm:692:17
WebGL context was lost. 2 Troubleshoot.jsm:692:17
Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified 4
sendRemoveListener on closed conduit {7a7a4a92-a2a0-41d1-9fd7-1e92480d612d}.274877908345 ConduitsChild.jsm:108
sendRemoveListener on closed conduit {7a7a4a92-a2a0-41d1-9fd7-1e92480d612d}.274877908326 ConduitsChild.jsm:108
sendRemoveListener on closed conduit linkificator@markapola.274877908327 ConduitsChild.jsm:108
sendRemoveListener on closed conduit {7a7a4a92-a2a0-41d1-9fd7-1e92480d612d}.274877908353 ConduitsChild.jsm:108
sendRemoveListener on closed conduit linkificator@markapola.274877908354 ConduitsChild.jsm:108
I will attach the errors with stacktraces expanded.
BTW when currently clicking in the browser window with popups not appearing, or immediately disappearing, I see no errors additionally in the browser console.
|
|
||
Comment 9•3 years ago
|
||
(In reply to aggregat4 from comment #6)
Thanks for all the info!
I do realize and apologize for the hard to reproduce nature of this thing. I
have been trying everything I could think off, but still run into the issue
and this was my way to try a last ditch approach to resolve this.
No need to apologize! We like fixing bugs - in fact, it's usually more frustrating from our perspective if people report an issue and then they disappear when we have follow-up questions -- understandable from their perspective, for sure, but of course it usually means we can't fix the issue if we are missing information to narrow down the cause.
However, your report has already helped me identify at least 1 specific issue in Firefox, though I suspect it is not related to your menus not working. I filed it separately as bug 1719754. (It means that you may not get adequate notifications of your firefox account, if any, signing in and/or having trouble signing in. I tracked this down from the fxaButton is null errors in your browser console log. But I don't think it should break anything else. You can doublecheck by going into customize mode and putting the firefox account button back into the/a toolbar. I suspect that won't fix the popup issue, but I could be wrong...)
The remaining items:
WebExtensions: reset-default-search: starting. api.js:183 WebExtensions: reset-default-search: has already ran once and saw panel, exit. api.js:210 Tried to send a 'target-destroyed-form' event on an already destroyed actor 'watcher' 2 Actor.js:58:15 Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. background.js:2 Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. background.js:2 Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. background.js:2 Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. background.js:2 Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. background.js:2 Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified 4 sendRemoveListener on closed conduit {7a7a4a92-a2a0-41d1-9fd7-1e92480d612d}.274877908345 ConduitsChild.jsm:108 sendRemoveListener on closed conduit {7a7a4a92-a2a0-41d1-9fd7-1e92480d612d}.274877908326 ConduitsChild.jsm:108 sendRemoveListener on closed conduit linkificator@markapola.274877908327 ConduitsChild.jsm:108 sendRemoveListener on closed conduit {7a7a4a92-a2a0-41d1-9fd7-1e92480d612d}.274877908353 ConduitsChild.jsm:108 sendRemoveListener on closed conduit linkificator@markapola.274877908354 ConduitsChild.jsm:108
All appear related to extensions (add-ons).
> WebGL context was lost. 2 Troubleshoot.jsm:692:17
> WebGL context was lost. 2 Troubleshoot.jsm:692:17
> WebGL context was lost. 2 Troubleshoot.jsm:692:17
is some graphics thing from loading about:support. I suspect this is also unrelated.
At this point I hope our Linux/GTK gurus have ideas on how to track this down further, so I'm going to move it over there.
|
||
Comment 10•3 years ago
|
||
I wonder whether this might be the same issue as bug 787943. Is the XIM input method in use?
https://developer.gnome.org/gtk3/stable/GtkIMContext.html#GtkIMContext.description has some hints about how the input method might be selected. lsof might be the most reliable way to determine which, if any, input method module is loaded in the process.
I expect GTK_IM_MODULE=gtk-im-context-simple in the environment would override whatever the system has selected.
|
|
||
Comment 11•3 years ago
|
||
https://bugs.freedesktop.org/show_bug.cgi?id=39367 says the XIM bug should be fixed.
Running Firefox with MOZ_LOG=WidgetPopup:5 in the environment is likely to provide some clues in the logging.
|
Reporter | |
Comment 12•3 years ago
|
||
I'm not sure how to use lsof to check for the IM module being used but an lsof + grep on immodules yields the following output:
firefox 27568 terzic mem REG 0,25 107391221 /usr/lib/gtk-3.0/3.0.0/immodules/im-ibus.so (path dev=0,26)
Which I would interpret as firefox using ibus, which appears to be the default for gnome.
I have also started firefox with MOZ_LOG=WidgetPopup:5 set and will report back when I get more output.
|
|
Reporter | |
Comment 13•3 years ago
|
||
Having started Firefox with MOZ_LOG=WidgetPopup:5 firefox and waiting until the problem occurs again I have only the following messages on the console (4 times the same message):
###!!! [Parent][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost
###!!! [Parent][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost
###!!! [Parent][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost
###!!! [Parent][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost
|
|
Reporter | |
Comment 14•3 years ago
|
||
BTW I don't think those messages are related to the problem since after restarting Firefox I can see them now in the console now and the popups still work.
|
||
Comment 15•3 years ago
•
|
||
(In reply to Karl Tomlinson (:karlt) from comment #11)
https://bugs.freedesktop.org/show_bug.cgi?id=39367 says the XIM bug should be fixed.
That bug should have been fixed by now. :-) (The patch was incorporated in August, 2013.)
Running Firefox with
MOZ_LOG=WidgetPopup:5in the environment is likely to provide some clues in the logging.
Since I never experienced this pulldown menu issue with Firefox that runs under Windows 10, I agree that this problem is linux-specific.
OTOH, I have not used firefox under linux extensively (I am using Debian GNU/Linux), I have not seen the same issue as the original reporter yet.
[Oh, I have to clarify my usage of input method. GDK 3.x or Debian, to be exact, has decided to ditch XIM from the standard distribution and thus I was forced to add im-xim.so in the place where such copy was expected.
Here is the list of copies on my linux installation.
Actually, gtk-2.x and gtk-3.y had an issue of drawing the proper rectangle on the indicator that XIM is in use, and I was forced to
patch the code and create a patched binary even when im-xim.so was supported in gtk-2.0.
root@ip030:/NEW-SSD/FF-NEW#
/OLD-USR-DIR/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-xim.so
/OLD-USR-DIR/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-xim.so.SAVE
/OLD-USR-DIR/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-xim.so
/OLD-USR-DIR/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-xim.so.saved
/OLD-USR-DIR/local/lib/gtk-2.0/2.10.0/immodules/im-xim.so
/home/ishikawa/repos/gtk+/modules/input/.libs/im-xim.so
/home/ishikawa/repos/gtk+/modules/input/.libs/im-xim.soT
/home/ishikawa/repos/gtk+-2.24.18/modules/input/.libs/im-xim.so
/home/ishikawa/repos/vmware-tools-distrib/lib/lib32/libconf/gtk-2.0/2.10.0/immodules/im-xim.so
/home/ishikawa/repos/vmware-tools-distrib/lib/lib64/libconf/gtk-2.0/2.10.0/immodules/im-xim.so
/home/ishikawa/vmware-tools-distrib/lib/lib32/libconf/gtk-2.0/2.10.0/immodules/im-xim.so
/home/ishikawa/vmware-tools-distrib/lib/lib64/libconf/gtk-2.0/2.10.0/immodules/im-xim.so
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-xim.so
/usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-xim.so
At the office (which I have not visited due to Covid-19 telecommuting mode), I use Thunderbird with XIM immodule and have not had this pull down menu issue for many years, but that was with im-xim.so.
I wonder if the latest gtk-3.x im-ibus.so has an issue?
But if so, we may have a big voice from many more users.
Original reporter, can you check the content of ~/.xsession-errors?
If I recall correctly, I could gather that window manger, etc. was confused due to strange timestamp there.
See, for example, https://bugzilla.mozilla.org/show_bug.cgi?id=787943#c12
|
|
||
Comment 16•3 years ago
|
||
(In reply to aggregat4 from comment #12)
Which I would interpret as firefox using ibus, which appears to be the default for gnome.
Yes. Thanks!
(In reply to aggregat4 from comment #13)
Having started Firefox with
MOZ_LOG=WidgetPopup:5 firefoxand waiting until the problem occurs again I have only the following messages on the console (4 times the same message):
Sorry, I see that "WidgetPopup" is new in Firefox 90. So, either MOZ_LOG=Widget:5 firefox is necessary, or wait a couple of days for Firefox 90.
|
|
Reporter | |
Comment 17•3 years ago
|
||
I ran it again with the older MOZ_LOG setting and I got a lot more output on the console. Here is the snippet that directly correlates to me right clicking on the page, the popup appearing and immediately disappearing:
[Parent 38637: Main Thread]: D/Widget Button 3 press on 7f078a399800
[Parent 38637: Main Thread]: D/Widget CaptureRollupEvents 7f07318c9800 1
[Parent 38637: Main Thread]: D/Widget GrabPointer time=0x60ec2402 retry=0
[Parent 38637: Main Thread]: D/Widget GrabPointer: window not visible
[Parent 38637: Main Thread]: D/Widget nsWindow::Show [7f07318c9800] state 1
[Parent 38637: Main Thread]: D/Widget calling gtk_widget_show(mShell)
[Parent 38637: Main Thread]: D/Widget nsWindow::ApplySizeConstraints [7f078a399800] min size 450 95
[Parent 38637: Main Thread]: D/Widget nsWindow::ApplySizeConstraints [7f078a399800] max size 16384 16384
[Parent 38637: Main Thread]: D/Widget nsWindow::OnWindowStateEvent [7f07318c9800] for 7f0747a33260 changed 0x1 new_window_state 0x80
[Parent 38637: Main Thread]: D/Widget early return because no interesting bits changed
[Parent 38637: Main Thread]: D/Widget nsWindow::OnWindowStateEvent [7f07318c9800] for 7f077b658e80 changed 0x1 new_window_state 0x80
[Parent 38637: Main Thread]: D/Widget GrabPointer time=0x60ec2402 retry=1
[Parent 38637: Main Thread]: D/Widget GrabPointer: pointer grab failed: 2
[Parent 38637: Main Thread]: D/Widget quick return because IS_MOZ_CONTAINER(aWidget) is true
[Parent 38637: Main Thread]: D/Widget CaptureRollupEvents 7f07318c9800 0
[Parent 38637: Main Thread]: D/Widget ReleaseGrabs
[Parent 38637: Main Thread]: D/Widget nsWindow::Show [7f07318c9800] state 0
[Parent 38637: Main Thread]: D/Widget nsWindow::OnWindowStateEvent [7f07318c9800] for 7f0747a33260 changed 0x1 new_window_state 0x81
[Parent 38637: Main Thread]: D/Widget early return because no interesting bits changed
[Parent 38637: Main Thread]: D/Widget nsWindow::OnWindowStateEvent [7f07318c9800] for 7f077b658e80 changed 0x1 new_window_state 0x81
[Parent 38637: Main Thread]: D/Widget quick return because IS_MOZ_CONTAINER(aWidget) is true
[Parent 38637: Main Thread]: D/Widget nsWindow::ApplySizeConstraints [7f078a399800] min size 450 95
[Parent 38637: Main Thread]: D/Widget nsWindow::ApplySizeConstraints [7f078a399800] max size 16384 16384
[Parent 38637: Main Thread]: D/Widget Button 3 release on 7f078a399800
|
|
||
Comment 18•3 years ago
|
||
(In reply to aggregat4 from comment #17)
[Parent 38637: Main Thread]: D/Widget GrabPointer time=0x60ec2402 retry=1
[Parent 38637: Main Thread]: D/Widget GrabPointer: pointer grab failed: 2
2 is GDK_GRAB_INVALID_TIME, which makes this look similar to the XIM issue, even though ibus is involved here.
The time can be converted to decimal, with for example echo $((0x60ec2402)), and compared with timestamps from xev and _NET_WM_USER_TIME from xprop.
Running with GTK_IM_MODULE=gtk-im-context-simple in the environment should disable ibus, which would be useful to confirm or exclude its involvement.
As implied in commen 15, some other app may also log anomalies, but different display managers sometimes send these somewhere other than ~/.xsession-errors.
|
|
Reporter | |
Comment 19•3 years ago
|
||
(In reply to Karl Tomlinson (:karlt) from comment #18)
Thanks for the analysis!
I find no .xsession-errors file on my machine. I will try a run with GTK_IM_MODULE=gtk-im-context-simple and report back.
|
||
Updated•3 years ago
|
|
|
Reporter | |
Comment 20•3 years ago
|
||
Okay, I just did a run with GTK_IM_MODULE=gtk-im-context-simple and the problem persists. I did not have the extended widget logging enable, so I will try that in combination next.
Question to those who know: if that GTK error indicates some time parsing problem, is there anything I can tweak on my system to change these timestamps? What timestamps are these?
|
|
Reporter | |
Comment 21•3 years ago
|
||
Here is the log output of MOZ_LOG=Widget:5 whilst also running with GTK_IM_MODULE=gtk-im-context-simple. The popup issue persists, this is the output from triggering the popup to it disappearing:
[Parent 20872: Main Thread]: D/Widget Button 3 press on 7f68b8679000
[Parent 20872: Main Thread]: D/Widget nsWindow::OnWindowStateEvent [7f68b8679000] for 7f68b867b260 changed 0x80 new_window_state 0x80
[Parent 20872: Main Thread]: D/Widget early return because no interesting bits changed
[Parent 20872: Main Thread]: D/Widget nsWindow::OnWindowStateEvent [7f68b8679000] for 7f68c260d970 changed 0x80 new_window_state 0x80
[Parent 20872: Main Thread]: D/Widget quick return because IS_MOZ_CONTAINER(aWidget) is true
[Parent 20872: Main Thread]: D/Widget CaptureRollupEvents 7f6849018c00 1
[Parent 20872: Main Thread]: D/Widget GrabPointer time=0x60ed874f retry=0
[Parent 20872: Main Thread]: D/Widget GrabPointer: window not visible
[Parent 20872: Main Thread]: D/Widget nsWindow::Move [7f6849018c00] 2292.000000 560.000000
[Parent 20872: Main Thread]: D/Widget nsWindow::NativeMove [7f6849018c00] 2292 560
[Parent 20872: Main Thread]: D/Widget nsWindow::Show [7f6849018c00] state 1
[Parent 20872: Main Thread]: D/Widget calling gtk_widget_show(mShell)
[Parent 20872: Main Thread]: D/Widget nsWindow::ApplySizeConstraints [7f68b8679000] min size 450 95
[Parent 20872: Main Thread]: D/Widget nsWindow::ApplySizeConstraints [7f68b8679000] max size 16384 16384
[Parent 20872: Main Thread]: D/Widget nsWindow::OnWindowStateEvent [7f6849018c00] for 7f684901ca60 changed 0x1 new_window_state 0x80
[Parent 20872: Main Thread]: D/Widget early return because no interesting bits changed
[Parent 20872: Main Thread]: D/Widget nsWindow::OnWindowStateEvent [7f6849018c00] for 7f68946f8530 changed 0x1 new_window_state 0x80
[Parent 20872: Main Thread]: D/Widget GrabPointer time=0x60ed874f retry=1
[Parent 20872: Main Thread]: D/Widget GrabPointer: pointer grab failed: 2
[Parent 20872: Main Thread]: D/Widget quick return because IS_MOZ_CONTAINER(aWidget) is true
[Parent 20872: Main Thread]: D/Widget configure event [7f6849018c00] 2292 560 276 318
[Parent 20872: Main Thread]: D/Widget GetScreenBounds [7f6849018c00] 2292,560 -> 276 x 318, unscaled 2292,560 -> 276 x 318
[Parent 20872: Main Thread]: D/Widget CaptureRollupEvents 7f6849018c00 0
[Parent 20872: Main Thread]: D/Widget ReleaseGrabs
[Parent 20872: Main Thread]: D/Widget nsWindow::Show [7f6849018c00] state 0
[Parent 20872: Main Thread]: D/Widget nsWindow::OnWindowStateEvent [7f6849018c00] for 7f684901ca60 changed 0x1 new_window_state 0x81
[Parent 20872: Main Thread]: D/Widget early return because no interesting bits changed
[Parent 20872: Main Thread]: D/Widget nsWindow::OnWindowStateEvent [7f6849018c00] for 7f68946f8530 changed 0x1 new_window_state 0x81
[Parent 20872: Main Thread]: D/Widget quick return because IS_MOZ_CONTAINER(aWidget) is true
[Parent 20872: Main Thread]: D/Widget nsWindow::ApplySizeConstraints [7f68b8679000] min size 450 95
[Parent 20872: Main Thread]: D/Widget nsWindow::ApplySizeConstraints [7f68b8679000] max size 16384 16384
[Parent 20872: Main Thread]: D/Widget Button 3 release on 7f68b8679000
|
|
Reporter | |
Comment 22•3 years ago
|
||
I figured out the cause for this behaviour: I had another application running that when used was generating event timestamps that were system timestamps and therefore usually wrong. This application was using gtk::show_uri to open a URL that was then opened in firefox. Presumably transferring the timestamp to Firefox proper?
As was noted in other issues discussed in this thread, firefox hangs on to timestamps and once a bad one gets saved it tends to get reused.
This issue can be resolved.
Additionally it may be useful if Firefox was more hardened against invalid timestamps generated by completely different applications.
|
|
||
Comment 23•3 years ago
|
||
The bug may be related to the bug in other programs.
I just noticed that there is a report of a similar bug in the following URL.
https://bugzilla.redhat.com/show_bug.cgi?id=1242210
Also, very old rant about the bug which seems relevant here.
https://smuxi.im/issues/show/579
Just my two cents worth.
|
|
Reporter | |
Comment 24•3 years ago
|
||
(In reply to ISHIKAWA, Chiaki from comment #23)
The bug may be related to the bug in other programs.
I just noticed that there is a report of a similar bug in the following URL.
https://bugzilla.redhat.com/show_bug.cgi?id=1242210
Also, very old rant about the bug which seems relevant here.
https://smuxi.im/issues/show/579Just my two cents worth.
Thanks for the additional information! Your many updates in #787943 (from 9 years ago!) were very helpful in tracking down the issue with Firefox in my case. I have only very limited experience in working with GTK but this timestamp based event stuff seems pretty error-prone to me.
I will resolve this issue as invalid.
|
|
||
Comment 25•3 years ago
|
||
(In reply to boris from comment #24)
(In reply to ISHIKAWA, Chiaki from comment #23)
...Thanks for the additional information! Your many updates in #787943 (from 9 years ago!) were very helpful in tracking down the issue with Firefox in my case. I have only very limited experience in working with GTK but this timestamp based event stuff seems pretty error-prone to me.
You are welcome. Time flies, erh?
This timestamp issue is very fragile, but as long as GTK is used, there does not seem to be a good solution.
I will resolve this issue as invalid.
Description
•