-
Notifications
You must be signed in to change notification settings - Fork 35
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
Comments
I can confirm the same behaviour on linux. I suppose it had something to do with the latest Firefox update. |
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. |
I confirm as well. |
Could we reach out to someone in your team? |
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. |
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. |
@msnspk Thank you very much for the analysis. |
I will attempt to replicate this on my current arch Linux install and get back to you. (Was on manjaro Linux 5.10) |
Experiencing the same issue as #400 (comment) |
Attempting to resolve this issue I found a workaround that seems okay to me. See https://superuser.com/questions/1644079/disable-firefox-select-context-menu-item-on-rmb-release |
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.
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. |
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. |
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: |
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? |
That solves this issue. |
Works for me, thanks! |
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! |
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! |
This is a viable workaround - #400 (comment) |
While the workaround offer some mitigation, it does not address the root cause of the bug. |
IMO, to address the root cause of the bug, we would have to:
Even if possible, I do not like the idea of always blocking normal behavior and triggering context menu with an add-on. |
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. |
Please also remove the "wontfix" label @cpriest |
Actually, it is Windows that does not care about the default Firefox behavior (which is "context menu on mouse down"). |
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. |
In Context menu should show on mouse down (and Linux correctly does that while Windows shows the context menu on mouse up instead) |
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 |
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 ? |
Thank you. Should we create a new label "Depends on Firefox fix", that can be added for this issue? @cpriest |
Thank you. |
Which of these bugs do you think has the greatest impact? |
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"
}
}
]
|
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 |
The text was updated successfully, but these errors were encountered: