Right click pulls context menu before snap drag in Firefox_Linux

Question

Right click pulls context menu before snap drag in Firefox_Linux

Opened this issue 3 years ago · 38 comments

Answer 1 · 2021-12-14T07:45:35.000Z

I can confirm the same behaviour on linux. I suppose it had something to do with the latest Firefox update.

Answer 2 · 2021-12-15T15:01:26.000Z

PR's welcome, I'm not sure I would be able to look into this anytime soon; I don't have any sort of Linux X/Wayland setup at this time.

Answer 3 · 2021-12-18T20:41:44.000Z

I confirm as well.

Answer 4 · 2021-12-22T13:36:47.000Z

PR's welcome, I'm not sure I would be able to look into this anytime soon; I don't have any sort of Linux X/Wayland setup at this time.

Could we reach out to someone in your team?

Answer 5 · 2021-12-23T13:20:43.000Z

I might have time to take a look into that between Christmas and New Year. I've the issue too and it should not be too hard to fix.

Answer 6 · 2021-12-24T05:22:34.000Z

I have always had the issue on Linux in Firefox that when right-clicking and dragging to use SnapLinks, the context menu appears first.

On the first right-click-and-drag, SnapLinks still works, but the context menu also appears and I cannot use SnapLinks to scroll the page. The second time I right-click-and-drag, the context menu disappears and SnapLinks works perfectly. Every time a page is (re)loaded, the context menu returns on the first instance of a right click-and-drag.

I use the linux-mainline package from the Arch Linux AUR, currently version 5.16-rc6 and now in Firefox on Linux SnapLinks periodically stops working entirely, not showing up when I right-click-and-drag. I have to not only restart Firefox, but my entire computer, to get the extension working again.

Booting instead into the current Arch Linux kernel version 5.15.11.arch2-1 SnapLinks in Firefox works consistently well without issue present in the mainline version.

Answer 7 · 2021-12-25T03:09:13.000Z

@msnspk Thank you very much for the analysis.

Answer 8 · 2022-01-01T10:42:02.000Z

I have always had the issue on Linux in Firefox that when right-clicking and dragging to use SnapLinks, the context menu appears first.

On the first right-click-and-drag, SnapLinks still works, but the context menu also appears and I cannot use SnapLinks to scroll the page. The second time I right-click-and-drag, the context menu disappears and SnapLinks works perfectly. Every time a page is (re)loaded, the context menu returns on the first instance of a right click-and-drag.

I use the linux-mainline package from the Arch Linux AUR, currently version 5.16-rc6 and now in Firefox on Linux SnapLinks periodically stops working entirely, not showing up when I right-click-and-drag. I have to not only restart Firefox, but my entire computer, to get the extension working again.

Booting instead into the current Arch Linux kernel version 5.15.11.arch2-1 SnapLinks in Firefox works consistently well without issue present in the mainline version.

I will attempt to replicate this on my current arch Linux install and get back to you. (Was on manjaro Linux 5.10)

Answer 9 · 2022-01-01T16:20:16.000Z

Experiencing the same issue as #400 (comment)
Normal right click also bleeds into snaplinksplus at times.

Answer 10 · 2022-01-02T13:15:07.000Z

Attempting to resolve this issue I found a workaround that seems okay to me.
In about:config we can toggle ui.context_menus.after_mouseup to true.

See https://superuser.com/questions/1644079/disable-firefox-select-context-menu-item-on-rmb-release

Answer 11 · 2022-01-02T13:17:46.000Z

It might be possible to have SLP3 to switch that setting. See https://stackoverflow.com/questions/29194144/firefox-addon-development-how-to-change-aboutconfig-setting

Answer 12 · 2022-01-02T13:29:22.000Z

It might be possible to have SLP3 to switch that setting. See https://stackoverflow.com/questions/29194144/firefox-addon-development-how-to-change-aboutconfig-setting

Thanks for looking into that @remi-garcia, turns out the SDK is long-since dead I think. None of the links I tried from that StackOverflow link to the SDK work.

Attempting to resolve this issue I found a workaround that seems okay to me. In about:config we can toggle ui.context_menus.after_mouseup to true.

Interestingly, I checked this setting on my Windows box and it is set to false, yet Firefox on Windows still does it on mouse up. A shame as that would have made for an easy fix to be able to know (via that setting), on which systems to use alternate behavior.

Answer 13 · 2022-01-02T13:30:28.000Z

A shame as that would have made for an easy fix to be able to know (via that setting), on which systems to use alternate behavior.

This is one of the big reasons I haven't tried to tackle this issue, I don't know a reliable method to know when to activate such alternate behavior.

Answer 14 · 2022-01-02T15:06:58.000Z

Interestingly, I checked this setting on my Windows box and it is set to false, yet Firefox on Windows still does it on mouse up.

I just shared that info as a joke on Windows...

I have dug a bit and I think we can confirm that we won't be able to modify this setting. Users have to do it by themselves. I think that we should provide info for Linux users on the tutorial page that link to this issue or a dedicated one.

Sources:
https://stackoverflow.com/questions/50023416/is-it-possible-to-create-a-firefox-webextension-that-changes-aboutconfig-settin/50024435
https://discourse.mozilla.org/t/webextension-read-write-access-to-about-config/12268

Answer 15 · 2022-01-02T15:08:26.000Z

I know this is not a proper fix but if it's worth anything, I'd like to let you know that this issue is not present on the Waterfox fork, I'm using the KPE edition of G4 on Arch KDE. (Incase you're trying to follow suit on this and also run KDE, then use the precompiled version from the AUR maintainer)

Answer 16 · 2022-01-05T10:40:34.000Z

I know this is not a proper fix but if it's worth anything, I'd like to let you know that this issue is not present on the Waterfox fork, I'm using the KPE edition of G4 on Arch KDE. (Incase you're trying to follow suit on this and also run KDE, then use the precompiled version from the AUR maintainer)

is it some specific version or should i just use yay to install this?

Answer 17 · 2022-01-05T12:19:08.000Z

In about:config we can toggle ui.context_menus.after_mouseup to true.

That solves this issue.

Answer 18 · 2022-01-05T12:43:55.000Z

Attempting to resolve this issue I found a workaround that seems okay to me. In about:config we can toggle ui.context_menus.after_mouseup to true.

See https://superuser.com/questions/1644079/disable-firefox-select-context-menu-item-on-rmb-release

Works for me, thanks!

Answer 19 · 2022-01-05T13:27:42.000Z

I know this is not a proper fix but if it's worth anything, I'd like to let you know that this issue is not present on the Waterfox fork, I'm using the KPE edition of G4 on Arch KDE. (Incase you're trying to follow suit on this and also run KDE, then use the precompiled version from the AUR maintainer)

is it some specific version or should i just use yay to install this?

https://aur.archlinux.org/packages/waterfox-g4-kpe/

Trying installing this via yay, if it doesn't compile (or if it brings up errors, then get the precompiled package from here https://software.opensuse.org//download.html?project=home%3Ahawkeye116477%3Awaterfox&package=waterfox-g4-kpe and install it via sudo pacman -U /path/to/the/package )

Hope that helps!

Answer 20 · 2022-01-27T11:19:41.000Z

Another workaround: Trigger the bug without opening any links once a page is loaded. On the same page, it will not open the context menu on a second shot!

Answer 21 · 2022-07-18T21:25:19.000Z

This is a viable workaround - #400 (comment)
Closing this issue.

Answer 22 · 2024-04-23T02:13:53.000Z

This is a viable workaround - #400 (comment) Closing this issue.

While the workaround offer some mitigation, it does not address the root cause of the bug.

Answer 23 · 2024-04-23T07:41:11.000Z

IMO, to address the root cause of the bug, we would have to:

Block normal behavior by preventing context menu from opening on click
Check if SLP3 is triggered
If not open context menu through the add-on

Even if possible, I do not like the idea of always blocking normal behavior and triggering context menu with an add-on.
Currently, the context menu opening is only blocked if SLP3 is triggered which seems to me less intrusive and prone to problems.

Answer 24 · 2024-04-29T15:37:07.000Z

This has always been the problem on some versions of Linux, Firefox (and possibly other apps) incorrectly trigger the context menu on mouse down instead of mouse up. It's one reason why this has never been addressed, because there are people on boths sides of the issue with differing opinions.

Answer 25 · 2024-04-30T18:29:42.000Z

This has always been the problem on some versions of Linux, Firefox (and possibly other apps) incorrectly trigger the context menu on mouse down instead of mouse up. It's one reason why this has never been addressed, because there are people on boths sides of the issue with differing opinions.

Fair. Well, considering the nuanced nature of the issue and the differing opinions expressed, it would be fair to reopen the bug report, IMO. This will provide an opportunity to revisit the problem, gather more information, and work towards a solution that takes into account the various stakeholders and their concerns.

Answer 26 · 2024-05-01T07:03:30.000Z

Please also remove the "wontfix" label @cpriest

Answer 27 · 2024-05-01T08:39:55.000Z

incorrectly trigger the context menu on mouse down instead of mouse up

Actually, it is Windows that does not care about the default Firefox behavior (which is "context menu on mouse down").
If at some point Windows starts to do things as they should be, according to Firefox parameters, the problem will not be limited to Linux.

Answer 28 · 2024-05-02T18:00:56.000Z

incorrectly trigger the context menu on mouse down instead of mouse up

Actually, it is Windows that does not care about the default Firefox behavior (which is "context menu on mouse down"). If at some point Windows starts to do things as they should be, according to Firefox parameters, the problem will not be limited to Linux.

I'm not sure what you mean? I'm on Windows, every app (including Firefox) properly shows the context menu on mouse up, not mouse down.

Answer 29 · 2024-05-03T08:53:17.000Z

In about:config, ui.context_menus.after_mouseup is false by default.

Context menu should show on mouse down (and Linux correctly does that while Windows shows the context menu on mouse up instead)

Answer 30 · 2024-05-08T18:44:35.000Z

Yeah, by industry standard UX/UI design methods it should be on mouse up. This gives the user a chance to change their mind by pressing escape. Without snaplinks enabled, on Windows, it shows after mouse up regardless of that about:config setting (I just tested it).

Answer 31 · 2024-05-09T07:41:34.000Z

Yeah, by industry standard UX/UI design methods it should be on mouse up.

I was not aware of that. It is strange that the default for Firefox is on mouse down 🤔

Answer 32 · 2024-05-13T02:30:16.000Z

Yeah, by industry standard UX/UI design methods it should be on mouse up.

I was not aware of that. It is strange that the default for Firefox is on mouse down 🤔

Should we check for a relevant default configuration or bug for Firefox at https://bugzilla.mozilla.org/describecomponents.cgi?product=Firefox ?

Answer 33 · 2024-05-13T12:07:16.000Z

xref: https://bugzilla.mozilla.org/show_bug.cgi?id=1443482 and https://bugzilla.mozilla.org/show_bug.cgi?id=1448442

Answer 34 · 2024-05-13T21:45:16.000Z

xref: https://bugzilla.mozilla.org/show_bug.cgi?id=1443482 and https://bugzilla.mozilla.org/show_bug.cgi?id=1448442

Thank you.

Should we create a new label "Depends on Firefox fix", that can be added for this issue? @cpriest

Answer 35 · 2024-05-14T20:14:32.000Z

xref: https://bugzilla.mozilla.org/show_bug.cgi?id=1443482 and https://bugzilla.mozilla.org/show_bug.cgi?id=1448442

Thank you.

Should we create a new label "Depends on Firefox fix", that can be added for this issue? @cpriest

Thank you.

Answer 36 · 2024-05-14T20:20:36.000Z

xref: https://bugzilla.mozilla.org/show_bug.cgi?id=1443482 and https://bugzilla.mozilla.org/show_bug.cgi?id=1448442

Which of these bugs do you think has the greatest impact?

Answer 37 · 2024-05-16T13:58:47.000Z

Number 1443482 On 5/14/2024 3:20 PM, David Hedlund wrote: xref: https://bugzilla.mozilla.org/show_bug.cgi?id=1443482 and https://bugzilla.mozilla.org/show_bug.cgi?id=1448442 Which of these bugs do you think has the greatest impact? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***> [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#400 (comment)", "url": "#400 (comment)", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

Answer 38 · 2024-05-17T04:53:37.000Z

Number 1443482

Thank you for reviewing these issues.

Given the lack of recent activity (9 months for 1443482 and over 2 years for 1448442), re-raising them as blockers for the add-on could be a productive next step. This would bring them to the developers' attention for a fresh review and potentially expedite resolution.

If you choose to post to these issues, kindly share your post links here for easy reference. @remi-garcia @cpriest