Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Right click pulls context menu before snap drag in Firefox_Linux #400

Open
beyond9thousand opened this issue Dec 10, 2021 · 38 comments
Open
Labels
contributor-needed Main developer won't likely implement, but not opposed to solution. depends-on-firefox-fix question verified Bug is reproducable

Comments

@beyond9thousand
Copy link

beyond9thousand commented Dec 10, 2021

image

@crxssrazr93
Copy link

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

@cpriest
Copy link
Owner

cpriest commented Dec 15, 2021

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
Copy link

I confirm as well.

@beyond9thousand
Copy link
Author

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 remi-garcia added the verified Bug is reproducable label Dec 23, 2021
@remi-garcia
Copy link
Collaborator

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
Copy link

msnspk commented Dec 24, 2021

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
Copy link

@msnspk Thank you very much for the analysis.

@beyond9thousand
Copy link
Author

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
Copy link
Author

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

@remi-garcia
Copy link
Collaborator

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 remi-garcia added question wontfix and removed verified Bug is reproducable labels Jan 2, 2022
@remi-garcia
Copy link
Collaborator

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
Copy link
Owner

cpriest commented Jan 2, 2022

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
Copy link
Owner

cpriest commented Jan 2, 2022

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
Copy link
Collaborator

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
Copy link

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
Copy link
Author

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
Copy link
Collaborator

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

That solves this issue.

@beyond9thousand
Copy link
Author

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
Copy link

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
Copy link

davidhedlund commented Jan 27, 2022

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
Copy link
Author

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

@davidhedlund
Copy link

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
Copy link
Collaborator

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
Copy link
Owner

cpriest commented Apr 29, 2024

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
Copy link

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.

@cpriest cpriest reopened this Apr 30, 2024
@davidhedlund
Copy link

Please also remove the "wontfix" label @cpriest

@remi-garcia
Copy link
Collaborator

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.

@remi-garcia remi-garcia added contributor-needed Main developer won't likely implement, but not opposed to solution. and removed wontfix doc labels May 1, 2024
@cpriest
Copy link
Owner

cpriest commented May 2, 2024

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
Copy link
Collaborator

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
Copy link
Owner

cpriest commented May 8, 2024

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
Copy link
Collaborator

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
Copy link

davidhedlund commented May 13, 2024

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
Copy link
Collaborator

@davidhedlund
Copy link

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
Copy link

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
Copy link

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
Copy link
Owner

cpriest commented May 16, 2024 via email

@davidhedlund
Copy link

davidhedlund commented May 17, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contributor-needed Main developer won't likely implement, but not opposed to solution. depends-on-firefox-fix question verified Bug is reproducable
Projects
None yet
Development

No branches or pull requests

6 participants