search

cpriest / SnapLinksPlus

Snap Links Plus is a Browser Addon that lets you lasso links, checkboxes and other elements do things with them.
Other
203 stars 35 forks source link

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

Open beyond9thousand opened 2 years ago

beyond9thousand commented 2 years ago

image

crxssrazr93 commented 2 years ago

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

cpriest commented 2 years ago

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 commented 2 years ago

I confirm as well.

beyond9thousand commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@msnspk Thank you very much for the analysis.

beyond9thousand commented 2 years ago

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 commented 2 years ago

Experiencing the same issue as https://github.com/cpriest/SnapLinksPlus/issues/400#issuecomment-1000661350 Normal right click also bleeds into snaplinksplus at times.

remi-garcia commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

That solves this issue.

beyond9thousand commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

This is a viable workaround - https://github.com/cpriest/SnapLinksPlus/issues/400#issuecomment-1003714487 Closing this issue.

davidhedlund commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

Please also remove the "wontfix" label @cpriest

remi-garcia commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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

davidhedlund commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago 
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": "https://github.com/cpriest/SnapLinksPlus/issues/400#issuecomment-2111073856", "url": "https://github.com/cpriest/SnapLinksPlus/issues/400#issuecomment-2111073856", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

davidhedlund commented 5 months ago

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