2016394 - FVWM2 - depending on context menu positioning etc., clicking on some menu items from the Downloads toolbar button no longer works

Status: UNCONFIRMED

(Core :: Widget: Gtk, defect, P3)

Description

[Vincent Lefevre]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:147.0) Gecko/20100101 Firefox/147.0

Steps to reproduce:

1. Left-click on the Downloads toolbar button.
2. Right-click on one the the files: a menu appears with "Open in xpdf" (in my case), "Always Open In xpdf", "Show In Folder", "Go To Download Page", "Copy Download Link", etc.
3. Left-click on one of these menu items (see below).

Actual results:

For "Open in xpdf" and "Always Open In xpdf", this has the expected effect. But "Show In Folder", "Go To Download Page" and "Copy Download Link" do not have any effect.

Expected results:

For instance, "Copy Download Link" should copy the download link to the clipboard. But pasting shows that the clipboard has not changed.

Note that using "Show all downloads" just after step 1, then "Copy Download Link" works as expected. The issue occurs only with the menu from the toolbar button, as described above.

Comment 1

[Vincent Lefevre]

This issue actually occurs only with some particular download (I won't share the URL as it is from some intranet).

"Show In Folder" does not work at all, but this may be a separate issue, as it doesn't work either via "Show all downloads" (and I'm not sure whether it has ever worked here).

Comment 2

[:Gijs (he/him)]

This is very strange - I don't think anything changed wrt the popup on 147.

Are there errors in the browser console (ctrl-shift-j) when this happens? Are the errors different for "Show in folder" vs the other ones?

Also, can you check in about:support if this is a snap or flatpak setup?

Comment 3

[Vincent Lefevre]

I can reproduce the issue on a different machine, with a different URL. Perhaps it occurs when there is a single download.

(In reply to :Gijs (he/him) from comment #2)

Are there errors in the browser console (ctrl-shift-j) when this happens?

No, no errors.

Are the errors different for "Show in folder" vs the other ones?

For "Show in folder" only, I get messages on stderr (which appear in the terminal):

[Parent 48, Main Thread] WARNING: g_app_info_get_name: assertion 'G_IS_APP_INFO (appinfo)' failed: 'glib warning', file toolkit/xre/nsSigHandlers.cpp:201

(firefox:48): GLib-GIO-CRITICAL **: 12:12:36.208: g_app_info_get_name: assertion 'G_IS_APP_INFO (appinfo)' failed
[Parent 48, Main Thread] WARNING: g_app_info_get_icon: assertion 'G_IS_APP_INFO (appinfo)' failed: 'glib warning', file toolkit/xre/nsSigHandlers.cpp:201

(firefox:48): GLib-GIO-CRITICAL **: 12:12:36.208: g_app_info_get_icon: assertion 'G_IS_APP_INFO (appinfo)' failed
[Parent 48, Main Thread] WARNING: g_app_info_get_executable: assertion 'G_IS_APP_INFO (appinfo)' failed: 'glib warning', file toolkit/xre/nsSigHandlers.cpp:201

(firefox:48): GLib-GIO-CRITICAL **: 12:12:36.208: g_app_info_get_executable: assertion 'G_IS_APP_INFO (appinfo)' failed
[Parent 48, Main Thread] WARNING: g_app_info_get_name: assertion 'G_IS_APP_INFO (appinfo)' failed: 'glib warning', file toolkit/xre/nsSigHandlers.cpp:201

(firefox:48): GLib-GIO-CRITICAL **: 12:12:36.208: g_app_info_get_name: assertion 'G_IS_APP_INFO (appinfo)' failed
Failed to query file manager via ShowItems: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: org.freedesktop.DBus.Error.ServiceUnknown

Also, can you check in about:support if this is a snap or flatpak setup?

I cannot see anything related to that. FYI, this is Debian's firefox package, with firefox running in firejail. But since this occurs only for some menu items, I doubt that this matters (possibly except for "Show in folder", but this seems to be a different issue).

FYI, the "Clear Preview Panel" menu item works.

Comment 4

[Vincent Lefevre]

I can reproduce the issue on "Copy Download Link" with a new profile and firefox not running in firejail. But "Go To Download Page" works. However, there is one less item ("Open in xpdf"), which means that all the menu items are shifted upward. I'm starting to believe that this is related to events and possibly the position of the popups: seen that before due to my window manager, which is FVWM2. This would also explain the "with some particular download" in comment 1.

Comment 5

[Vincent Lefevre]

Attachment: screen recording showing the issue

I confirm that this is due to the position of the popups and the position of the click in the menu item. See this screen recording.

• On 00:04, I click on "Go To Download Page", at a position where below the menu, there is the main Firefox window. The click is ignored.
• On 00:08, I click on the same menu item, but at a position where below the menu, there is the Downloads panel. In this case, the click is taken into account.

Comment 6

[:Gijs (he/him)]

Thanks! Let's move this to GTK widget so folks who understand those bits of the world can take a look.

Comment 7

[Martin Stránský [:stransky] (ni? me)]

Please test latest nightly and run on terminal with MOZ_LOG="GIOService:5" env variable, reproduce the issue and attach the log here.
Thanks.

Comment 8

[Vincent Lefevre]

I cannot reproduce the issue with twm and FVWM3 (using Debian's default configuration). I can still reproduce it with FVWM2 using Debian's default configuration.

Though this may be specific to FVWM2, this seems to be a real bug in Firefox as there is no reason to ignore the click.

Comment 9

[Vincent Lefevre]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #7)

Please test latest nightly and run on terminal with MOZ_LOG="GIOService:5" env variable, reproduce the issue and attach the log here.

I don't see any log with

cventin:~/software/firefox> MOZ_LOG="GIOService:5" ./firefox

Comment 10

[Vincent Lefevre]

Oops, I wasn't running it in the right directory. Here's the log:

[Parent 324222: Main Thread]: D/GIOService nsGIOService::GetAppForURIScheme() http
[Parent 324222: Main Thread]: D/GIOService   g_app_info_get_default_for_uri_scheme() provides Firefox ESR : /usr/lib/firefox-esr/firefox-esr
[Parent 324222: Main Thread]: D/GIOService nsGIOService::GetAppForURIScheme() http
[Parent 324222: Main Thread]: D/GIOService   g_app_info_get_default_for_uri_scheme() provides Firefox ESR : /usr/lib/firefox-esr/firefox-esr
[Parent 324222: Main Thread]: D/GIOService nsGIOService::GetAppForURIScheme() http
[Parent 324222: Main Thread]: D/GIOService   g_app_info_get_default_for_uri_scheme() provides Firefox ESR : /usr/lib/firefox-esr/firefox-esr
[Parent 324222: Main Thread]: D/GIOService nsGIOService::GetAppForURIScheme() http
[Parent 324222: Main Thread]: D/GIOService   g_app_info_get_default_for_uri_scheme() provides Firefox ESR : /usr/lib/firefox-esr/firefox-esr
[Parent 324222: Main Thread]: D/GIOService nsGIOService::GetAppForMimeType() application/xml-external-parsed-entity
[Parent 324222: Main Thread]: D/GIOService   g_content_type_from_mime_type(application/xml-external-parsed-entity)
[Parent 324222: Main Thread]: D/GIOService   g_app_info_get_default_for_type() gives us winebrowser : env
[Parent 324222: Main Thread]: D/GIOService nsGIOService::GetAppForMimeType() application/postscript
[Parent 324222: Main Thread]: D/GIOService   g_content_type_from_mime_type(application/postscript)
[Parent 324222: Main Thread]: D/GIOService   g_app_info_get_default_for_type() gives us Inkscape : inkscape
[Parent 324222: Main Thread]: D/GIOService nsGIOService::GetAppForMimeType() application/postscript
[Parent 324222: Main Thread]: D/GIOService   g_content_type_from_mime_type(application/postscript)
[Parent 324222: Main Thread]: D/GIOService   g_app_info_get_default_for_type() gives us Inkscape : inkscape
[Parent 324222: Main Thread]: D/GIOService nsGIOService::GetAppForMimeType() application/gzip
[Parent 324222: Main Thread]: D/GIOService   g_content_type_from_mime_type(application/gzip)
[Parent 324222: Main Thread]: D/GIOService   g_app_info_get_default_for_type() gives us File Roller : file-roller
[Parent 324222: Main Thread]: D/GIOService nsGIOService::GetAppForMimeType() application/postscript
[Parent 324222: Main Thread]: D/GIOService   g_content_type_from_mime_type(application/postscript)
[Parent 324222: Main Thread]: D/GIOService   g_app_info_get_default_for_type() gives us Inkscape : inkscape
[Parent 324222: Main Thread]: D/GIOService nsGIOService::GetAppForMimeType() application/postscript
[Parent 324222: Main Thread]: D/GIOService   g_content_type_from_mime_type(application/postscript)
[Parent 324222: Main Thread]: D/GIOService   g_app_info_get_default_for_type() gives us Inkscape : inkscape
[Parent 324222: Main Thread]: D/GIOService nsGIOService::GetAppForMimeType() application/postscript
[Parent 324222: Main Thread]: D/GIOService   g_content_type_from_mime_type(application/postscript)
[Parent 324222: Main Thread]: D/GIOService   g_app_info_get_default_for_type() gives us Inkscape : inkscape
[Parent 324222: Main Thread]: D/GIOService nsGIOService::GetAppForMimeType() application/postscript
[Parent 324222: Main Thread]: D/GIOService   g_content_type_from_mime_type(application/postscript)
[Parent 324222: Main Thread]: D/GIOService   g_app_info_get_default_for_type() gives us Inkscape : inkscape

Comment 11

[Martin Stránský [:stransky] (ni? me)]

Frankly I have no idea. I wonder if the popup itself is not active (the click goes outside of the popup and just closes it) or we're missing target MIME type and silently ignore the result. But if that depends on the popup position I think the first variant here.

Can you please run on terminal with MOZ_LOG="Widget:5,WidgetPopup5" env variable, reproduce the bug once and attach the log here?
Thanks.

Comment 12

[Vincent Lefevre]

Attachment: logs with: MOZ_LOG="Widget:5,WidgetPopup5" ./firefox |& ts "[%H:%M:%.S]"

Here are the logs with MOZ_LOG="Widget:5,WidgetPopup5" ./firefox |& ts "[%H:%M:%.S]" using Nightly.

On 13:59:50, I did the click on "Go To Download Page" at a position over the Firefox window, and nothing happened.

On 13:59:56, I did the click on "Go To Download Page" at a position over the popup, and this worked, as explained in Comment 5.

Comment 13

[Vincent Lefevre]

I've noticed another thing: in case 1, the download panel (popup) disappears when I click; but in case 2, the download page is opened as requested, and the download panel remains open.

Comment 14

[Vincent Lefevre]

It seems that in case 1, Firefox thinks that the click occurred in the Firefox window, which would explain why the download panel disappears.

Moreover, if I move the mouse pointer over the menu item between the button press and the button release, the behavior depends on the location of the mouse pointer when I release the mouse button (not its location when I pressed the button).

Comment 15

[Martin Stránský [:stransky] (ni? me)]

Sorry, I requested wrong log - it's missing WaylandPopup part as it was WidgetPopup5 instead of WidgetPopup:5.
Please try again the wrong case but with:

MOZ_LOG="Widget:5,WidgetPopup:5"

Thanks.

Comment 16

[Vincent Lefevre]

Attachment: logs with: MOZ_LOG="Widget:5,WidgetPopup:5" ./firefox |& ts "[%H:%M:%.S]"

On 15:56:00, I did the click on "Go To Download Page" at a position over the download panel, and this was taken into account: download page opened in a new tab; the download panel remained open.

On 15:56:10, I did the click on "Go To Download Page" at a position over the Firefox window, and the download page did not open; both the menu and the download panel disappeared.

Comment 17

[Martin Stránský [:stransky] (ni? me)]

Can you try to set widget.gtk.grab-pointer to 1 at about:config, restart browser and try again?
May be related to Bug 1807482
https://searchfox.org/firefox-main/rev/22d04b52b0eb8d9fa11bf8ede5ccc0243a07c5ba/widget/gtk/nsWindow.cpp#3816
Thanks.

Comment 18

[Martin Stránský [:stransky] (ni? me)]

Also do you see it as a recent regression? Did it work before?

Comment 19

[Vincent Lefevre]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #17)

Can you try to set widget.gtk.grab-pointer to 1 at about:config, restart browser and try again?

Same behavior. This does not solve the problem.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #18)

Also do you see it as a recent regression? Did it work before?

This is a regression. 140.8.0esr works fine.

Comment 20

[Vincent Lefevre]

More precisely, FF 145 is fine, but not FF 146.

Comment 21

[Martin Stránský [:stransky] (ni? me)]

I see. Can you try to use mozregression to find the broken commit?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Use_Mozregression_tool
Thanks.

Comment 22

[Vincent Lefevre]

With mozregression:
5:43.40 INFO: Last good revision: 6488d90a06c0b99c9f7000b8c0763c4f44253912
5:43.40 INFO: First bad revision: ebd252259b1b0cb286e12edc2e14b9f483444920
5:43.40 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6488d90a06c0b99c9f7000b8c0763c4f44253912&tochange=ebd252259b1b0cb286e12edc2e14b9f483444920

Comment 23

[Martin Stránský [:stransky] (ni? me)]

Thanks - I don't see anything obviously related within the regression range.