Right click pulls context menu before snap drag in Firefox_Linux

[beyond9thousand]

[crxssrazr93]

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

[cpriest]

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.

[davidhedlund]

I confirm as well.

[beyond9thousand]

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?

[remi-garcia]

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.

[msnspk]

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.

[davidhedlund]

@msnspk Thank you very much for the analysis.

[beyond9thousand]

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)

[beyond9thousand]

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

[remi-garcia]

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

[remi-garcia]

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

[cpriest]

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.

[cpriest]

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.

[remi-garcia]

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

[crxssrazr93]

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)

[beyond9thousand]

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?

[remi-garcia]

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

That solves this issue.

[beyond9thousand]

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!

[crxssrazr93]

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!

[davidhedlund]

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!

[beyond9thousand]

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

[davidhedlund]

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.

[remi-garcia]

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

1. Block normal behavior by preventing context menu from opening on click
2. Check if SLP3 is triggered
3. 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.

[cpriest]

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.

[davidhedlund]

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.

[davidhedlund]

Please also remove the "wontfix" label @cpriest

[remi-garcia]

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.

[cpriest]

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.

[remi-garcia]

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)

[cpriest]

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).

[remi-garcia]

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 🤔

[davidhedlund]

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 ?

[remi-garcia]

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

[davidhedlund]

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

[davidhedlund]

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.

[davidhedlund]

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?

[cpriest]

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" } } ]

[davidhedlund]

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