Closed Bug 1360278 Opened 7 years ago Closed 7 years ago

Want a preference to enable context menu on mouse up (for mouse gestures)

Categories

(Core :: DOM: UI Events & Focus Handling, enhancement, P5)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
Unspecified
Linux
Type:
enhancement

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla59
Tracking Flags:
Tracking Status
firefox57 - wontfix
firefox58 --- fixed
firefox59 --- verified

People

(Reporter: mark, Assigned: robin.grenet, NeedInfo)

References

Details

Attachments

(1 file, 6 obsolete files)

Bug 1360278 - Add preference to trigger context menu on mouse up for GTK+ and macOS,
59 bytes, text/x-review-board-request
smaug
: review+
mstange
: review+
gchang
: approval-mozilla-beta+
Details 
Current behavior:

On Windows, contextmenu is fired on mouse up. On every other OS, contextmenu is fired on mouse down.

Desired behavior:

A preference to make contextmenu always fire on mouse up, or a means to programmatically open the contextmenu,

Use case:

I'm trying to write a mouse gestures web extension and I want to support gestures using right mouse button on OSX/Linux

FireGestures is a popular mouse gestures (legacy) extension that forces the contextmenu on mouse up behavior when installed on OSX/Linux.

There is no way to replicate the FireGestures functionality using web extensions APIs.

I need a preference that I can advise users to change, or a means of programmatically opening the context menu.

More information:

I need contextmenu to fire on mouse up because I recognize gestures using the following pseudo-code:

1. on mousedown -> mouseMoved = false
2. on mousemove -> mouseMoved = true
3. on mouseup -> if mouseMoved { handle gesture }
4. on contextmenu -> if mouseMoved { event.preventDefault() }

If contextmenu occurs before mousemove, I do not know if I should call event.preventDefault().

Alternatively, if I could programmatically open a context menu I would just always call event.preventDefault() and then handle everything on mouse up.
It sounds like an event handling rather than a behavior preference.
Component: Menus → WebExtensions: Untriaged
Product: Firefox → Toolkit
Flags: needinfo?(amckay)
(In reply to mark from comment #0)
> I need a preference that I can advise users to change, or a means of
> programmatically opening the context menu.

We've already said no to programmatically opening the context menu because there wasn't a use case that made sense to us. Perhaps asking for the pref change to Firefox might be the way to go.
Flags: needinfo?(amckay)
Component: WebExtensions: Untriaged → General
Product: Toolkit → Firefox
Component: General → Event Handling
Product: Firefox → Core
Summary: [RFE] Preference to enable context menu on mouse up (for mouse gestures) → Want a preference to enable context menu on mouse up (for mouse gestures)
I don't know if this is what we'd consider and if there's potential risk to do this. WDY, Olli?
Flags: needinfo?(bugs)
This doesn't sound unreasonable, even though it is a tad annoying to break platform conventions when an addon is installed. But perhaps that is ok.
So I would take a patch which adds this kind of pref.
Flags: needinfo?(bugs)
Priority: -- → P5
Will this make it for FF57? I ask because without this behavior there is a gap for all Linux and Mac gestures users since no webextension alternative can be implemented.
We need this, since FireGestures is broken in Firefox Nightly 57 already and there is no viable alternative otherwise
I agree, I can't seem to find any gesture programs that work well in Firefox 57 and not being able to suppress these context menus is a huge blow to gesture users.
Please, try to make this somehow work. Otherwise Linux and Mac users are left without mouse gestures or on old versions of FF when 57 comes out.
I added this for gtk and it works like expected. I'm not sure if I chose the right way to make it configurable. Some feedback would be more then welcome.
Flags: needinfo?(bugs)
Doesn't look unreasonable. Need to support it on all the platforms.
Flags: needinfo?(bugs)
Windows is special anyway. They use the native behavior as I understand, which is context menu on mouse up (or whenever windows fires the context menu event).

I'll see what I can do for Mac. It might take a while since I need to borrow a Mac somewhere :/
[Tracking Requested - why for this release]:
tracking-firefox57: --- → ?
(In reply to Jj Del Carpio from comment #13)
> [Tracking Requested - why for this release]:

It's because Non-WebExtension mouse gesture addons stop working in Firefox 57 and WebExtension replacements need that.
Is somebody reviewing the attached patch? Is it possible to get this into Firefox 57 (so new Mouse Gesture addons work when legacy addons stop working)?
Doesn't sound like a blocker for 57.
tracking-firefox57: ? → -
(In reply to Julien Cristau [:jcristau] from comment #16)
> Doesn't sound like a blocker for 57.

So you don't care if Linux/Mac Firefox users can't use mouse gestures in Firefox 57? Is that what you are telling us?
FireGestures – the most popular non-WebExtension gesture software – has about 300k users. All-in-One Gestures has about 50k users. These are pretty popular extensions. I will be pretty bummed if they are all unusable in 57 on macOS.
(In reply to April King [:April] from comment #18)
> FireGestures – the most popular non-WebExtension gesture software – has
> about 300k users. All-in-One Gestures has about 50k users. These are pretty
> popular extensions. I will be pretty bummed if they are all unusable in 57
> on macOS.

Exactly! It should be a Must for Mozilla to have Mouse Gestures available and working on all platforms in Firefox 57.

There is a patch attached to this bug. Has anybody reviewed it? If a patch is available and this patch fixes the problem, it should definitely go into Firefox 57. Would be a shame if users were left without Mouse Gestures, even more so if a patch is available in time.
(In reply to Julien Cristau [:jcristau] from comment #16)
> Doesn't sound like a blocker for 57.

Well it should be a blocker. There is API for making those kinds of uses, there are plenty extensions that use that API but they don't work on Mac and linux distros (most of which have firefox bundled as a default browser) but you just ignore them because "choices were made".
I know that especially linux users have small market share and stuff, but most of them are power users that influence the common public. At least from my experiences from 4 European countries a lot of people have that "IT guy" who knows what's good and they listen to his voice.
I tried the patch attached but it did not work.
In order to work, I had to change on nsWindow.cpp file two things:

1. Remove code from OnButtonPressEvent:
    if (domButton == WidgetMouseEvent::eRightButton &&
        MOZ_LIKELY(!mIsDestroyed)) {
        WidgetMouseEvent contextMenuEvent(true, eContextMenu, this,
                                          WidgetMouseEvent::eReal);
        InitButtonEvent(contextMenuEvent, aEvent);
        contextMenuEvent.pressure = mLastMotionPressure;
        DispatchInputEvent(&contextMenuEvent);
    }
2. Place this same "if" without "&& MOZ_LIKELY(!mIsDestroyed)" to the end of OnButtonReleaseEvent:
    if (domButton == WidgetMouseEvent::eRightButton) {
        WidgetMouseEvent contextMenuEvent(true, eContextMenu, this,
                                          WidgetMouseEvent::eReal);
        InitButtonEvent(contextMenuEvent, aEvent);
        contextMenuEvent.pressure = mLastMotionPressure;
        DispatchInputEvent(&contextMenuEvent);
    }

The result is what I hoped it would be. 
Gestures working, and context menu appears only if my mouse did not move enough to activate gestures. 
Also, with gestures disabled, context menu appears at position where I release the button.

But I am not a firefox developer, I don't even know how to create a patch.
The firefox developers should consider fixing this the correct way, 
because I guess they chose to place context menu on OnButtonPressEvent for a good reason (which I don't know obviously).
Referring to my previous post, a small update. I did not have to remove "&& MOZ_LIKELY(!mIsDestroyed)" from this "if".
It works like this (changes on /widget/gtk/nsWindow.cpp):

1. Remove code from OnButtonPressEvent:
    if (domButton == WidgetMouseEvent::eRightButton &&
        MOZ_LIKELY(!mIsDestroyed)) {
        WidgetMouseEvent contextMenuEvent(true, eContextMenu, this,
                                          WidgetMouseEvent::eReal);
        InitButtonEvent(contextMenuEvent, aEvent);
        contextMenuEvent.pressure = mLastMotionPressure;
        DispatchInputEvent(&contextMenuEvent);
    }
2. Place this same "if" to the end of OnButtonReleaseEvent:
    if (domButton == WidgetMouseEvent::eRightButton &&
        MOZ_LIKELY(!mIsDestroyed)) {
        WidgetMouseEvent contextMenuEvent(true, eContextMenu, this,
                                          WidgetMouseEvent::eReal);
        InitButtonEvent(contextMenuEvent, aEvent);
        contextMenuEvent.pressure = mLastMotionPressure;
        DispatchInputEvent(&contextMenuEvent);
    }

ps. I use Linux and a mouse. I don't know how this will work on touch-pad or any other input device.
Move Context Menu initialization to OnButtonReleaseEvent, instead of OnButtonPressEvent.
I would like to chime in and add that an option to support this behavior would be greatly appreciated. Chrome has the same problem and they were not willing to support an option to help make this possible. I hope we can be more reasonable here.
(In reply to Markus Popp from comment #19)
> (In reply to April King [:April] from comment #18)
> > FireGestures – the most popular non-WebExtension gesture software – has
> > about 300k users. All-in-One Gestures has about 50k users. These are pretty
> > popular extensions. I will be pretty bummed if they are all unusable in 57
> > on macOS.
> 
> Exactly! It should be a Must for Mozilla to have Mouse Gestures available
> and working on all platforms in Firefox 57.

FYI, Mouse Gesture Events works around this by requiring users to right-click twice to open the context menu. Works once you get used to it.

https://addons.mozilla.org/en-US/firefox/addon/mouse-gestures/
(In reply to nrlz from comment #25)
> FYI, Mouse Gesture Events works around this by requiring users to
> right-click twice to open the context menu. Works once you get used to it.

This may be fine as short term workaround, but shouldn't stop anybody from fixing this issue ASAP.

Linux and OS X users shouldn't be 2nd class citizens and have mouse gestures without limitations available just like Windows users.
Could this issue please at least be marked as confirmed? Currently the status is Unconfirmed. What more is needed to confirm this?

I'm surprised that it isn't marked as affecting firefox57.
Marking as confirmed, as this issue exists. If this is something that is decided not to implement, please resolve accordingly after the decision is made.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → Linux
Version: 53 Branch → unspecified
(In reply to Michal Stanke (Mozilla.cz) [:MikkCZ][:mstanke] (use needinfo) from comment #28)
> If this is something that is decided not to implement, 

That would mean leaving Linux and OS X Firefox users without Mouse Gestures, or only in very limited ways which are a huge regression in terms of user experience.

Also, patches are available (see above) and while there may be some minor things to sort out, it should be possible to get this into the main code rather soon.
Hello,

For linux users using deb system (debian, ubuntu, etc) with amd64 architecture, I have managed to create a deb installation file for testing purposes.
Please find firefox 57 beta installation file in the url provided.
The sources are synchronized up to 04 October 2017 and it includes the fix attached on this page.

This will install a new application named "firefoxtest", and it will overide firefox when you launch normal firefox.
Please test it and let firefox team know if this is working as expected. 
A feedback would be nice from users with other input devices than mouse (touchpad, touchscreen etc)

You may check what files this package will install using command:
	$ dpkg-deb -c firefox.beta.04.10.2017.deb
Mainly, it will place those files/dir in your system
	- FILE: /usr/local/bin/firefox
	- DIR : /usr/local/lib/firefox-57.0/

Steps to install/uninstall:
- Install firefox stable normally, if you haven't already. (from OS repository)
- Download deb file from url
	https://drive.google.com/open?id=0BxTM5PFrlyZed0xVSUxrdVUzOUE
- Install this file using command:
	$ sudo dpkg -i firefox.beta.04.10.2017.deb
- Launch firefox normally, the test version should start. Otherwise launch it from /usr/local/bin/firefox .
	$ cd /usr/local/bin/
	$ ./firefox
- Uninstall the installation using command:
	$ sudo apt-get remove firefoxtest
Once uninstalled, normal firefox will launch again.

I am using this with ubuntu and Gnome Shell for some weeks now, but it should work on all Desktop environments.
Firefox team would be great to provide us test cases if they need help testing the patches.

Regards
Hi dimimeim,

works great for me in combination with "Foxy Gestures". I'm also running Ubuntu 17.04 and Gnome Shell.

Thank you very much for your efforts!
I can also confirm that it works in Ubuntu 17.10 beta 2 with "Foxy Gestures".

I did try it with Ubuntu 16.04 and 14.04 too, and there firefox wouldn't start. The error from Ubuntu 14.04 was:

base@peter:~> firefox
firefox: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by firefox)

(That probably has no bearing on whether the right-click patches work though)
What are the chances of this patch making it into the final Firefox 57?
This does not meet the criteria for uplift into 57.
I'd imagine we'd need a setting to opt into the non-native context menu behavior, at the very least. I am hopeful that this does land, but it needs to be fully baked first.
I haven't read the entire history here but :smaug was asking about exposing preferences to webextensions.  We do this for things like the browserSettings [1] and privacy [2] apis.  For a simple preference, the code to implement one of these for webextensions is pretty simple, see something like [3] for an example.

[1] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/browserSettings
[2] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/privacy
[3] http://searchfox.org/mozilla-central/rev/7ba03cebf1dcf3b4c40c85a4efad42a5022cf1ec/toolkit/components/extensions/ext-privacy.js#63-71
Move context menu popup using mouse right button, from onPress to onRelease with option to activate/deactivate this functionality.
Hello,

I made another patch to have option on "about:config" page. Please find it attached on this page. (bug-1360278-fix-with-option)
This option is called input.contextMmenu.onRelease, and is by default False.
In order to test this patch, you can turn this value to True.

This option is made thanks to Andrew Swan, who instructed on previous post how to do this.

For (debian system) linux users with amd64 architecture, I have also made another build synchronized up to 07.10.2017, 
with this boolean option on about:config page called "input.contextMmenu.onRelease" for testing purposes.

Please find this updated deb file on:
	https://drive.google.com/open?id=0BxTM5PFrlyZeWnBlVkJRRjdOQ1U

You can find instructions on my previous post in order to install on your linux system.
You may need to uninstall previous version first with this command:
	$ sudo apt-get remove firefoxtest

In case a library is missing on old OS, you can try to install firefox-beta normally (from ppa or any other way). 
This should resolve missing libraries. Then there should be no issue running this build.

Regards
Hey,

Is there a macOS specific build or patch that I could test?

Cheers
Is it possible to get dimimeim's patch into Firefox Nightly in time for Firefox 58.0 at least? (if uplifting to 57.0 is not possible)

I tested it on Xubuntu 17.10 and works fine.
Andrew, I see a patch attached here. Is there someone who can pick it up for review?
Flags: needinfo?(overholt)
Could you use Preferences::AddBoolVarCache for the pref.
And no need for == false or == true.
Just !expr or expr
Seems smaug has already taken a look. Maybe dimimeim can update their patch given comment 42 and request review from smaug? If someone else like Karl has to review, too, given his gtk widget module ownership, let's do that.
Flags: needinfo?(overholt) → needinfo?(dimimeim)
Bug 1360278 fix. Variable on About:config page "input.contextMmenu.onRelease" should be set to true to test this fix.
Attachment #8909017 - Attachment is obsolete: true
Attachment #8916272 - Attachment is obsolete: true
Flags: needinfo?(dimimeim)
Hello,

I added Preferences::AddBoolVarCache to the patch as you suggested.
I made another build for testing. This build is synchronized up to 16/10/2017. 
Anyone willing to test should read my previous posts for instructions. (Only linux users as mentioned on previous posts. )
You may find the new deb file here:
	https://drive.google.com/open?id=0BxTM5PFrlyZeYXRrNFh5cFRJWWc
Please check the attached patch and let me know if everything is okay.

Regards
I tested Attachment #8919045 [details] [diff] on my Linux (Fedora 27)
WebExtension gestures works fine now.

However, the menu would appear when Right_Click, not Right_Release. That is to say, the menu would exists on the page while I'm drawing my gestures.

Besides, on Windows, the menu would appear when Right_Release.
I have tested this on KDE neon too. I only had to install manually a dependency.

1. Are you sure you are running the patched version of Firefox?
   You can tell that you are running the patched version if you can see on "about:config" page, Boolean option  
   "input.contextMmenu.onRelease" (by default false).
2. Did you change this option (input.contextMmenu.onRelease) to true? (Otherwise the patch is not active.)
Flags: needinfo?(litimetal)
I have tested that patched version of Firefox on Arch Linux x86_64, and it works with Foxy Gestures after turning on the input.contextMmenu.onRelease option.
My procedure:
1. Confirm that I applied and compiled with  Attachment #8919045 [details] [diff]
2. Use a new profile, install Foxy Gestures
3. Right click, the behavior is the same as Comment 46 
4. about:config  input.contextMmenu.onRelease is false. Turn it to true
5. Foxy Gesture works fine now
Flags: needinfo?(litimetal)
Would really be great if somebody could try this patch on OSX too. And try a patched version on Windows without setting the about:config  input.contextMmenu.onRelease to make sure that we don't break windows.

Alas, I'm not volunteering...
Any body test this on mac os x? would this patch be merged in official firefox?
This does not appear to work on macOS. I see the setting in about:config, but changing it does not change behavior.
(In reply to crazymykl from comment #52)
> This does not appear to work on macOS. I see the setting in about:config,
> but changing it does not change behavior.

Which version firefox do you use? I'm using night 58.0a, in which I can't find the setting in about:config.
(In reply to onlyqupeng from comment #53)
> Which version firefox do you use? I'm using night 58.0a, in which I can't
> find the setting in about:config.

If you mean the regular Nightly, the patch is not included there yet. That's what we all are desperately waiting for (increasingly uneasy because the next merge day is less than 2 weeks away).

I don't know if there is a patched OS X build. Comment 45 only mentions a Linux .deb build.
To be clear, I compiled from source with the patch applied. There is no binary macOS build.
Why extention can't just get direct access to the input events!?! Additional permission won't ruin security, but absence of that feature will defenetly lower user experience - addons must have access to everything - that is the point of it. 

TWO! Of my most beloved gesture and keystroke extentions is legacy and never will be updated because of that...
BTW, js injections is lowering security much more than input events access.
Perhaps this bug isn't a Firefox bug but a bug in Foxy Gestures? I'm on a Mac and decided to try testing the patch. Since I haven't done any Firefox development before now it took me 3 days of pushing files around to make enough room to build and to learn how to build it locally. After building a working copy of Firefox 58 (58.0a1 (2017-11-04) (64-bit)) I loaded the "Foxy Gestures" extension and the context menu still showed up. So I started debugging the patch given here and some things didn't look right so I changed things but still had the context menu show up. So I dug into the Foxy Gestures code and stumbled on this piece in "mouseEvents.js" (in Foxy Gestures):

Beginning of window.addEventListener:

  window.addEventListener('contextmenu', function (event) {
    // Disable the context menu event after a gesture.
    if (!state.contextMenu ||
      (state.gestureState !== GESTURE_STATE.NONE) &&
      (state.gestureState !== GESTURE_STATE.MOUSE_DOWN)
    ) {
      event.preventDefault();
      event.stopPropagation();
    }

Note that the if statement condition (3rd line) that should detect a context menu click and disable it:

  if (!state.contextMenu || ...

that means, I think, to suppress the context menu if it ISN'T a context menu click. I believe it should say:
 
  if (state.contextMenu || ...

so it would suppress the context menu if it IS a context menu click.

I spent some more time to learn about Web Extension debugging, made the above change and ran it using my local Firefox 58 build and Foxy Gestures worked for me (using the right mouse click for gesture activation, btw) without the context menu popping up during or after a gesture was performed.

BTW, I started to write this and started having doubts so I reran my Firefox build with both the original and the modified Foxy Gesture extensions and had the same result: it functioned correctly w/o the extraneous context menu when using the changes to the extension.

All this is new enough for me that I feel the need to have my results double checked by someone. I know I should handle this as an issue for Foxy Gestures as well but at this point I'm really sick of doing anything else with it just now (though I have no regrets about having done what I have.) I hope this resolves the problem though I know there could be many other problems not yet thought about.
Flags: needinfo?(mark)
Damn, I knew I shouldn't hit return too quickly!

I just realized that I used my corrected version of Firefox 58 (with the patch given here that I had changed in order to test things on a Mac) so although I can say that Foxy Gestures didn't run correctly on a Mac with just the patch given here I need to back out my changes and do a few more tests before saying exactly what happens using my changed copy of Foxy Gestures as well as the original with Firefox 58 without my changes. More testing that I hope won't take too long tonight and I'll add more when I know the results. Sorry for the premature conclusion.

Just to make that clear:

- I still believe the Foxy Gestures extension has an error that may affect the issue here.

- I'm not sure how my own patch and/or the patch suggested here will affect things and am in the process of testing that.
Flags: needinfo?(mark)
OK, Waiting for a long compile but at this point I know that:

- When I tried the patch proposed here with the release version of Foxy Gestures it failed to fix the context menu issue.
- Running just the Foxy Gestures change with the current release of Firefox does not work (the context menu still appears).
- I have a successful patch that along with the change I mentioned about Foxy Gestures does eliminate the context menu issue.
- The remaining unknown is whether the current patch proposed here combined with the change to Foxy Gestures will work or not.

So once I've got a good local build of Firefox 58 I'll test both the patch above and, if necessary, the patch I made with both the Foxy Gestures with and without the fix I proposed. and post the results once that's done.
(In reply to Zhora VandenBout from comment #60)
> OK, Waiting for a long compile but at this point I know that:
> 
> - When I tried the patch proposed here with the release version of Foxy
> Gestures it failed to fix the context menu issue.
> - Running just the Foxy Gestures change with the current release of Firefoxmailto:zhora@sonic.net
> does not work (the context menu still appears).
> - I have a successful patch that along with the change I mentioned about
> Foxy Gestures does eliminate the context menu issue.
> - The remaining unknown is whether the current patch proposed here combined
> with the change to Foxy Gestures will work or not.
> 
> So once I've got a good local build of Firefox 58 I'll test both the patch
> above and, if necessary, the patch I made with both the Foxy Gestures with
> and without the fix I proposed. and post the results once that's done.

The real question for me is, does the context menu appear when you:
- use the patched firefox build
- activate the patch in about:config
- hold the right mouse button (without releasing it immediately)
- without any addons/extensions activated?

The context menu should appear on mouse-up but not on mouse-down.
(In reply to Zhora VandenBout from comment #59)
> Damn, I knew I shouldn't hit return too quickly!
> 
> I just realized that I used my corrected version of Firefox 58 (with the
> patch given here that I had changed in order to test things on a Mac) so
> although I can say that Foxy Gestures didn't run correctly on a Mac with
> just the patch given here I need to back out my changes and do a few more
> tests before saying exactly what happens using my changed copy of Foxy
> Gestures as well as the original with Firefox 58 without my changes. More
> testing that I hope won't take too long tonight and I'll add more when I
> know the results. Sorry for the premature conclusion.
> 
> Just to make that clear:
> 
> - I still believe the Foxy Gestures extension has an error that may affect
> the issue here.
> 
> - I'm not sure how my own patch and/or the patch suggested here will affect
> things and am in the process of testing that.

Your interpretation of the contextmenu handler in Foxy Gestures is incorrect. state.contextMenu is a flag in FG code that is true when the context menu must be allowed, and false when it should be prevented. From the way you wrote, it sounds like you didn't understand that 'contextmenu' is a distinct event fired by the browser. There is no such thing as a click that is a context menu or a click that isn't a context menu. 

Anyway, it is irrelevant. The test for this issue is as robbendebiene says. Is the contextmenu event fired when the right button is pressed or released?
The patches attached to this bug only touch widget/gtk (and the prefs repo file, all.js), which is not used on macOS (which uses widget/cocoa). They will therefore not affect macOS and it is a waste of time to check this.
Thanks for your work guys, Is it usual for the Mozilla team to ignore patches by the community and do not include them on the nightly?
(In reply to nev3rkill from comment #64)
> Thanks for your work guys, Is it usual for the Mozilla team to ignore
> patches by the community and do not include them on the nightly?

It's not being "ignored" - no review was requested, and from comment 46-49, it's not clear the patch works correctly. The patches have been reviewed before now. Either way, the patch is also incomplete in terms of fixing this bug, because it doesn't address macOS.

What needs to happen next is someone needs to upload a combined patch, clarify whether it works correctly vs. what's happening in comment 46-49, and request review using the appropriate flags -- but that would only help on Linux/BSD/... Ideally we'd need another patch for macOS, which would also need review.
Tested on GalliumOS (Ubuntu 16.04) using #45's build, https://addons.mozilla.org/en-US/firefox/addon/foxy-gestures/ and mouse rocker gestures. Works perfectly when enabled, right to left rocker gesture fails when disabled. In normal usage when enabled the context menu appears on release instead of click. When disabled it appears on click. 

Hope the macOS situation can be worked out, eager to see this patch added.
(In reply to dimimeim from comment #44)
> "input.contextMmenu.onRelease" should be set to true to test this fix.

A typo. Should be contextMenu, not contextMmenu
I suggest that this bug should be split into two, one for GNU/Linux, the other for macOS. It is unreasonable to expect that a single volunteer will contribute a patch that addresses both platform.

After the split, the solution presented here for GNU/Linux could be accepted into Nightly, and the macOS bug would wait for its champion.
(In reply to Yuri Khan from comment #68)
> I suggest that this bug should be split into two, one for GNU/Linux, the
> other for macOS. It is unreasonable to expect that a single volunteer will
> contribute a patch that addresses both platform.
> 
> After the split, the solution presented here for GNU/Linux could be accepted
> into Nightly, and the macOS bug would wait for its champion.

I wholeheartedly agree! Why should Linux users wait for an OS X fix if the fix for Linux is ready?
If you feel like cannot wait any longer, for Linux I highly recommend https://github.com/thjaeger/easystroke. I'm glad Mozilla was slow on this issue, that forced me to search for alternatives. Now I got my favorite gestures for the whole OS.
I also recommend easystroke as well as anything that has a keyboard hotkey can be made into a gesture and it will also work on all the pages web extensions aren't allowed on. That being said I also use rocker gestures to switch between tabs and easystroke doesn't support those so I still am waiting for this patch.
Like Sergey, I couldn't wait any longer, but I'm on MacOS. I found https://www.boastr.net is a universal gesture utility for MacOS that will map gestures to keyboard shortcuts, so I'm back in action now.

That being said, Firefox really should support this natively because what you really want to see is some visual feedback that you're in the process of swiping left or right, which a third-party gesture utility will never able to give you.
(In reply to josh.padnick from comment #73)
> That being said, Firefox really should support this natively because what
> you really want to see is some visual feedback that you're in the process of
> swiping left or right, which a third-party gesture utility will never able
> to give you.

Right, Firefox should support this natively and thanks to dimimeim's much appreciated work, a patch for Linux is available.

What frustrates me is that this patch isn't accepted into the main code and there seems to be no effort by Mozilla folks to get it there.

Now Nightly is at version 59 and I fear the doors to get the patch into Firefox 58 are closed. Even though with a little will it should still be possible provided that release date for Firefox 58.0 is mid-January.
Just so everybody is aware: As you may already know, the various mouse gesture extensions for Chrome on Linux only work because you have to double-right-click to get the right-click context-menu.

I'm preparing a patch to Foxy Gestures so it also (like Chrome) works around this issue with Firefox on Linux so that mouse gestures work on Linux even without this current issue resolved. The issue is being tracked here:

Double right-click to open context menu in OSX/Linux · Issue #67
https://github.com/marklieberman/foxygestures/issues/67

And the pull-request is here:
https://github.com/marklieberman/foxygestures/pull/69

It's not quite there yet. Mark Lieberman wisely suggested that this behavior should be behind an option so it can be disabled, and I'm still working on that part.

So there is hope for having gestures even with this issue unpatched, at the price of having to double-right-click to see the context-menu, just like in Chrome. Unfortunately, it won't be ready for the release of Firefox 57 today though.
@DEXTER: I would like to ask that we all keep the tone friendly and civil. 

I'm also affected by this so I feel your pain on this first day of living without mouse gestures on Linux. But I have to say that Firefox Quantum rocks.

So @DEXTER: Either be nice, or contribute to the solution. Remember, you're entitled to exactly what you're paying for. Bickering helps nobody.
I would like to help solving this issue. I know a bit of C++ but never used Objective-C before. Though, I think it would be nice to have a patch for both Linux and macOS, so I gave it a try. The patch included contains a fix for both Linux and macOS. The macOS part of the patch would need to be improved. But for now, I especially need to know if it works. As I'm currently on Linux, I can't test it on macOS. So it would be nice if mac users could test it and send feedback. Of course, Linux users’ feedback are welcome too.

To be more specific, on the Linux part, I used a global variable to cache the value of the preference. I don't know if it makes much of a difference, but it seems to me that the context menu should pop up as fast as possible. So caching the value saves us from retrieving it every mouse click.
I assign the global variable to the value of the pref in the initialize_prefs() function, which is called in the constructor of nsWindow. It seems to be the right place, but I don't really know if this function was meant for this.

On the mac side, the implementation is more basic, as we retrieve the value of the pref for each right click with Preferences::GetBool(). It could be improved later.

I also heard that the idea was to expose the preference to webextensions. It is not the case in this patch. I will try to look at this later.

Of course, any help would be much appreciated.
I tested your patch on macOS, and no dice. However, I have augmented it to make it work. The toggle is now respected with my patch.
This is confirmed to work on macOS 10.13.1.
For MacOS part you may want to ask mstange to review
I see that people have already suggested patches for this problem, but the bug is still in the NEW state, even though it is 7 months old. Are the patches not good enough? I will try it out for linux when I have the time.

I really like the new Firefox 57. The performance improvements are really noticeable, but I am afraid that if I won't be able to have some addons for context search and mouse gestures, all these improvements will be for nothing, as I will most probably  switch to chrome :(
FWIW, the patch from comment#44 (with the typo fixed as mentioned in comment#67) was accepted in the openSUSE's firefox package (https://build.opensuse.org/request/show/542056). The package will be submitted to the openSUSE:Factory repo 'soon'.

Extensions such as foxy gestures now work as expected.
Attachment #8928978 - Flags: review?(mstange)
dimimeim, do you need help to finish this patch? thanks
Flags: needinfo?(dimimeim)
> FWIW, the patch from comment#44 (with the typo fixed as mentioned in
> comment#67) was accepted in the openSUSE's firefox package
> (https://build.opensuse.org/request/show/542056). The package will be
> submitted to the openSUSE:Factory repo 'soon'.
We don't recommend such patches to be applied before they are reviewed by peers. This could cause some regressions to the Firefox package in opensuse.

As Olli suggested, I asked Markus if he could help with the mac version.
(In reply to Sylvestre Ledru [:sylvestre] from comment #88)
> > FWIW, the patch from comment#44 (with the typo fixed as mentioned in
> > comment#67) was accepted in the openSUSE's firefox package
> > (https://build.opensuse.org/request/show/542056). The package will be
> > submitted to the openSUSE:Factory repo 'soon'.
> We don't recommend such patches to be applied before they are reviewed by
> peers. This could cause some regressions to the Firefox package in opensuse.

All serious behavioral changes are behind a pref check and the pref is false by default. Therefore it was accepted to the first stage in openSUSE's development model. It is not scheduled nor included in any official release just yet.
JFYI
(In reply to Sylvestre Ledru [:sylvestre] from comment #88)
>
> We don't recommend such patches to be applied before they are reviewed by
> peers. This could cause some regressions to the Firefox package in opensuse.
> 
This regression is still marked as 'enhancement' after 7 months and was completely ignored before the Firefox 57 release.
You don't really expect the GNU/linux or Mac users will wait until the Firefox 58 or 59 release, right ?
> All serious behavioral changes are behind a pref check and the pref is false
> by default. Therefore it was accepted to the first stage in openSUSE's
> development model. It is not scheduled nor included in any official release
> just yet.
OK, thanks for the extra information. I don't have any issue with this solution!
(In reply to Sylvestre Ledru [:sylvestre] from comment #87)
> dimimeim, do you need help to finish this patch? thanks

Instead of reviewing attachment 8928978 [details] [diff] [review], I think mstange should review attachment 8929119 [details] [diff] [review] from comment 83. It is essentially the same but sends the correct event on right mouse up to popup the context menu on macOS. So maybe attachment 8928978 [details] [diff] [review] should be marked as obsolete, or modified to match attachment 8929119 [details] [diff] [review].

(In reply to Christophe Giboudeaux from comment #86)
> FWIW, the patch from comment#44 (with the typo fixed as mentioned in
> comment#67) was accepted in the openSUSE's firefox package
> (https://build.opensuse.org/request/show/542056). The package will be
> submitted to the openSUSE:Factory repo 'soon'.
> 
> Extensions such as foxy gestures now work as expected.

It is a good thing if we can get reviews from there. But don't rush, dimimeim's patch is far from being perfect.
And for those in a hurry, instead of just complaining here, maybe you should just build firefox yourself with this patch applied. I'm doing this myself for several weeks and it works fine. That's what free software if for.
Actually it IS important. Gestures are way more efficient for quick browsing than anything else and due this problem is firefox only one browser where it sucks.
We understand the frustration and the impact of this change for some people and I will contact some people. Now, please avoid the "metoo" messages.
Just FYI, I compiled Firefox 57 with Arch ABS using Robin's patch and it basically works bar one flaw- I'm not even sure the flaw is FF's problem or FoxyGestures' problem. The config option created by the patch works and indeed the context menu only presents on release. However if one uses the chord gesture Left+Right the context menu pops up after completing the action. So say Left+Right click is bound to open a new tab- the tab opens and the context menu pops up. All trail type gestures work fine- no context menu after completing their assigned action. All scroll actions work correctly as well (right click + scroll up or down).

Is this issue within the scope of the patch here, or should I create an Issue at FireGestures git page? Ideally when this patch is merged the mouse gestures extensions will properly handle it to avoid further need of changes. Thanks for the patch!
I can confirm OpenSuse patched version working flawlessly after enabling input.contextMenu.onRelease. Thanks to the package maintainters
I added a request in the Archlinux bugs team. Hopping they accept the patch too.

https://bugs.archlinux.org/task/56387?project=1&string=firefox
I've compiled Firefox on Arch with both Robin's patch and with dimimiem's patch separately. For me using FoxyGestures, Robin's patch is superior. Dimimiems patch doesnt seem to prevent the context menu from presenting on press, and though the gestures work a context menu always immediately pops up. Strangely, this does *not* occur using a Left+Right chord gesture to open a new tab- no context menu presents- while the same presents a context menu upon completion with Robin's patch. Dimimiem's patch will present a context menu just pressing and holding the right mouse button; Robin's patch does not present until I release the right mouse button.

Has anyone else tested these patches in comparison? I might try the v2 of Robin's patch, but as I understand its predominately modified for Mac OS.
(In reply to poeticrpm from comment #100)
> I've compiled Firefox on Arch with both Robin's patch and with dimimiem's
> patch separately. For me using FoxyGestures, Robin's patch is superior.
> Dimimiems patch doesnt seem to prevent the context menu from presenting on
> press, and though the gestures work a context menu always immediately pops
> up. Strangely, this does *not* occur using a Left+Right chord gesture to
> open a new tab- no context menu presents- while the same presents a context
> menu upon completion with Robin's patch. Dimimiem's patch will present a
> context menu just pressing and holding the right mouse button; Robin's patch
> does not present until I release the right mouse button.
> 
> Has anyone else tested these patches in comparison? I might try the v2 of
> Robin's patch, but as I understand its predominately modified for Mac OS.

I did notice with the test .deb above that with the smartUp gesture extension the context menu would still appear (after the gesture completed) while using the right to left chord gesture and would not appear using FoxyGestures. I suspect that some extensions might need additional code to take advantage of the the patch.
Attachment #8928978 - Attachment is obsolete: true
Attachment #8928978 - Flags: review?(mstange)
Attachment #8929119 - Attachment is obsolete: true
Attachment #8919045 - Attachment is obsolete: true
Attachment #8898802 - Attachment is obsolete: true
Comment on attachment 8930206 [details]
Bug 1360278 - Add preference to trigger context menu on mouse up for GTK+ and macOS,

https://reviewboard.mozilla.org/r/201360/#review206464

The Mac part looks good to me. I'm not comfortable reviewing the Linux part.
Attachment #8930206 - Flags: review?(mstange) → review+
I've taken Robin's patch and moved the lazy pref getter into nsBaseWidget, so that the macOS nsWindow implementation can use it too. I couldn't see any examples of how to create a single static pref cache in the macOS code so I figured this would be simpler and would avoid hardcoding the pref name in multiple places.

I've also renamed the pref to ui.context_menu.on_release and grouped it with the other "ui." prefs because there seem to be no existing preferences that start "input.", and this seemed to fit better with existing things like toggling popup autohide which already use this prefix.

I have only tested this patch on macOS so far.

Olli, if you want someone else to review this (maybe karlt?) please forward as appropriate. Ditto for Markus if you're busy (maybe :spohl?).

I can try writing an automated test, but I expect it'll be painful because we'd need to use native events from within a browser mochitest or something, so I haven't done it so far.
Flags: needinfo?(dimimeim)
Comment on attachment 8930206 [details]
Bug 1360278 - Add preference to trigger context menu on mouse up for GTK+ and macOS,

https://reviewboard.mozilla.org/r/201360/#review206484

::: widget/nsBaseWidget.cpp:1225
(Diff revision 1)
>  
> +// static
> +bool
> +nsBaseWidget::ShowContextMenuOnRelease()
> +{
> +  static bool gContextMenuOnClickRelease = false;

OnClickRelease sounds odd. 
gContentMenuAfterMouseUp perhaps?

::: widget/nsBaseWidget.cpp:1229
(Diff revision 1)
> +{
> +  static bool gContextMenuOnClickRelease = false;
> +  static bool gContextMenuOnClickReleaseCached = false;
> +  if (!gContextMenuOnClickReleaseCached) {
> +    Preferences::AddBoolVarCache(&gContextMenuOnClickRelease,
> +                                 "ui.context_menus.on_release",

perhaps ui.context_menus.after_mouseup or so.
Attachment #8930206 - Flags: review?(bugs) → review+
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/f540f9e801cb
Add preference to trigger context menu on mouse up for GTK+ and macOS, r=mstange,smaug
https://hg.mozilla.org/mozilla-central/rev/f540f9e801cb
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox59: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Wolfgang, if  you are still planning to keep the patch in Opensuse, could you take the patch which landed in nightly?
Thanks
Assignee: nobody → robin.grenet
status-firefox57: --- → wontfix
status-firefox58: --- → wontfix
Flags: needinfo?(mozilla)
Gijs, follow up of our private irc chat, as it is behind a pref, do you want to uplift that?
(gerry will make the call)
status-firefox58: wontfix → affected
(In reply to Sylvestre Ledru [:sylvestre] from comment #112)
> Gijs, follow up of our private irc chat, as it is behind a pref, do you want
> to uplift that?
> (gerry will make the call)

Yes, assuming people can verify this fixes the issue for them. Today's morning macOS and Linux nightlies finished, so if people  confirm that this is fixed (the pref you want to flip in about:config is:

ui.context_menus.after_mouseup

) that would be helpful.

Download links from treeherder ( https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&revision=72ee4800d4156931c89b58bd807af4a3083702bb&filter-searchStr=build%20nightly&selectedJob=146354051 ) are:

https://queue.taskcluster.net/v1/task/FPirK7uOSSCHkqK0D-QvBA/runs/0/artifacts/public/build/target.dmg

for macOS and

https://queue.taskcluster.net/v1/task/AMC9UmETQCiJFdNotEuYpQ/runs/0/artifacts/public/build/target.tar.bz2

for Linux x64 and

https://queue.taskcluster.net/v1/task/ewdqKEFuQa-r5Z9t5pV0XA/runs/0/artifacts/public/build/target.tar.bz2

for Linux 32-bit.

(usual disclaimers for nightly builds apply, you may want to use a separate profile etc. etc.)
Flags: needinfo?(robin.grenet)
Flags: needinfo?(peter)
Flags: needinfo?(markus.popp)
Flags: needinfo?(mark)
Works like a charm for me @OpenSuse tumbleweed with latest nightly x64
This has been accepted and backported on Archlinux's official repo under extra\firefox 57.0-2 and it's already online.

https://bugs.archlinux.org/task/56387

Thanks for the work :)
Works perfectly on ubuntu 16.04 using the 64-bit nightly from Comment #113
Thanks for the confirmation this works on Linux. It would be nice if someone else could confirm this also works on macOS.
Flags: needinfo?(markus.popp)
Flags: needinfo?(mark)
Works fine on Ubuntu 18.04 64-bit
Comment on attachment 8930206 [details]
Bug 1360278 - Add preference to trigger context menu on mouse up for GTK+ and macOS,

Approval Request Comment
[Feature/Bug causing the regression]: n/a
[User impact if declined]: users who rely on mouse gestures made with the right mouse button can't easily use those gestures because the context menu pops up immediately on mousedown, on Linux/macOS.
[Is this code covered by automated tests?]: general context menu functionality has automated test coverage. There isn't specific test coverage for the pref this patch adds.
[Has the fix been verified in Nightly?]: So far, it's been verified on Linux, still waiting on confirmation from macOS users.
[Needs manual test from QE? If yes, steps to reproduce]: Given the community interest, I expect their efforts are better spent elsewhere.
[List of other uplifts needed for the feature/fix]: n/a
[Is the change risky?]: no
[Why is the change risky/not risky?]: all the changes are guarded behind a pref that has no UI and is off by default. It's an opt-in change for people who need this behaviour.
[String changes made/needed]: nope
Attachment #8930206 - Flags: approval-mozilla-beta?
Confirmed working on macOS 10.13.1.
Thanks! Marking this verified per the feedback so far. Leaving ni for Peter in case he wants to add anything, given he's the author of one of the relevant webextension add-ons here. (Peter: If not, feel free to just clear the needinfo request.)
Status: RESOLVED → VERIFIED
status-firefox59: fixed → verified
Flags: needinfo?(robin.grenet)
Hello Robbendebiene/Gesturefy, (or someone who knows how to contact...)

I accidentally triggered the right-click behaviour. It could be a possible solution. At least as long Firefox doesn't change.

– Linux Mint 18.2, Firefox 57
– I have installed the Gesturefy-add-on set with right-click
– on website https://dev.twitch.tv/extensions, I accidentally right-clicked the video
  (screenshots on imgur: https://imgur.com/a/1Rxbm)
– the video is embedded in an iframe
– maybe there is a time-racing going on between right-click and iframe-something
– the drawing canvas inside the "div" with "z-index:1999999999" stays sticky
– the drawing disappears sometimes over time (seconds), opening the Firefox-Dev-Tool, clicking randomly or reloading the site

I know it is a kind of a glitch. But it could be used to solve/bootstrap the right-click problem after closer inspections.

Good luck.
(In reply to HellebardeFox from comment #122)
> Hello Robbendebiene/Gesturefy, (or someone who knows how to contact...)
> 
> I accidentally triggered the right-click behaviour. It could be a possible
> solution. At least as long Firefox doesn't change.
> 
> – Linux Mint 18.2, Firefox 57
> – I have installed the Gesturefy-add-on set with right-click
> – on website https://dev.twitch.tv/extensions, I accidentally right-clicked
> the video
>   (screenshots on imgur: https://imgur.com/a/1Rxbm)
> – the video is embedded in an iframe
> – maybe there is a time-racing going on between right-click and
> iframe-something
> – the drawing canvas inside the "div" with "z-index:1999999999" stays sticky
> – the drawing disappears sometimes over time (seconds), opening the
> Firefox-Dev-Tool, clicking randomly or reloading the site
> 
> I know it is a kind of a glitch. But it could be used to solve/bootstrap the
> right-click problem after closer inspections.
> 
> Good luck.

Hi, there is a GitHub page where Gesturefy has its sources and you can also file issues there. It might be related to this issue https://github.com/Robbendebiene/Gesturefy/issues/148
(In reply to :Gijs from comment #121)
> Thanks! Marking this verified per the feedback so far. Leaving ni for Peter
> in case he wants to add anything, given he's the author of one of the
> relevant webextension add-ons here. (Peter: If not, feel free to just clear
> the needinfo request.)

Hello, I'm not a developer, but I guess that the new preference is not visible for webextensions, right?
It would be great for the gestures developers to determine if they want to change that preference or use a workaround (or let the user choose from both).
Also I have no idea how much work is it to make it work as comment 36 describes.
Thanks
Blocks: 1419426
(In reply to Stanislav Marek from comment #124)
> (In reply to :Gijs from comment #121)
> > Thanks! Marking this verified per the feedback so far. Leaving ni for Peter
> > in case he wants to add anything, given he's the author of one of the
> > relevant webextension add-ons here. (Peter: If not, feel free to just clear
> > the needinfo request.)
> 
> Hello, I'm not a developer, but I guess that the new preference is not
> visible for webextensions, right?

No. I filed bug 1419426 about this.
Works great with Gesturefy (after manually switching the preference) in today's Linux64-Nightly on Xubuntu 16.04 LTS.

Any chance to get this fix uplifted to Firefox 58.0 Beta?
(In reply to Markus Popp from comment #126)
> Any chance to get this fix uplifted to Firefox 58.0 Beta?
This is what comment #119 is about. Gerry will make the call on that.
(In reply to :Gijs from comment #125)
> No. I filed bug 1419426 about this.

Thanks a lot! Looks promising :)
Comment on attachment 8930206 [details]
Bug 1360278 - Add preference to trigger context menu on mouse up for GTK+ and macOS,

Let's take this for the users who rely on mouse gestures made with the right mouse button plus this is behind a pref control. Beta58+.
Attachment #8930206 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
(In reply to Sylvestre Ledru [:sylvestre] from comment #111)
> Wolfgang, if  you are still planning to keep the patch in Opensuse, could
> you take the patch which landed in nightly?

did so
Flags: needinfo?(mozilla)
Nothing important, but I just wanted to note, that the AMO verification tool outputs the following warning:

browserSettings.contextMenuShowEvent is not supported
Warnung: This API has not been implemented by Firefox.
(In reply to robbendebiene from comment #133)
> Nothing important, but I just wanted to note, that the AMO verification tool
> outputs the following warning:
> 
> browserSettings.contextMenuShowEvent is not supported
> Warnung: This API has not been implemented by Firefox.

Andreas, do you know where we can get this fixed?
Flags: needinfo?(awagner)
This didn't get added in our Firefox 58 update for the addons-linter since it was uplifted. The Firefox 59 update last landed on the master branch there so AMO may be updated with it this Thursday, next Thursday for sure.
Flags: needinfo?(awagner)
I merged the 59 schema import and cherry-picked it into this week's deploy so that it'll land on Thursday in production on AMO. Thanks everyone!
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: