New issue
Advanced search Search tips
Starred by 67 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Nov 2009
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment

Right-click context menu shouldn't show before mouseup.

Reported by, Nov 2 2009

Issue description

Chrome Version       : (Official Build 29902)
OS version               : 10.5.8
Behavior in Safari 3.x/4.x (if applicable): Same issue.
Behavior in Firefox 3.x (if applicable): Fine.
Behavior in Chrome for Windows: Fine.

The right-click context menu shows right after mousedown in Mac Chrome, it 
should show after mouseup.

This issue breaks some javascripts that handle the contextmenu, and almost 
all mouse-gesture extensions.

Status: WontFix
Mac Chrome (Official Build 30554)

zhouguiheng, I just tried with Firefox 3.5.4 and Safari 4.0.3. I am not seeing any 
difference than Mac Chrome.

- Press right click, hold it.

- context menu shows up.

Let me know if I am missing anything. I will re-open this bug.
That's weird. I tried with Firefox 3.5.4 again, but the context menu doesn't show up 
until I release the right mouse button. This behavior is same as chrome in linux and 

Let me explain it more technically. I care it because I am writing a simple mouse 
gesture extensions for mac chrome. The event "contextmenu" is triggered while the 
button is still holding, it makes me hard/impossible to determine when to call 
event.preventDefault(). Normally, "contextmenu" event should be triggered after the 
right mouse button is released.

I also tried two other mouse gestures ( and nk-, both don't work in mac chrome.

Comment 3 by, Nov 2 2009

I think in this regard we would like to mimic what it is that Safari/most Mac apps do.  
TextEdit and iChat also work in this same manner.
So we want to keep inconsistent behavior among chrome in different OS? Since chrome 
would finally launch extension support in stable version, I think it would better to keep 
the behavior consistent for webpage.

I agree that we should mimic mac apps for tabs/app menus/skin, etc, but for the web 
page, I think we should make the event triggering logic consistent. I was very happy 
that all add-ons I ever used in Linux Firefox worked well in Mac Firefox, but chrome? 
Why does a developer have to write different code for mac chrome extension?

Comment 5 by, Nov 5 2009

This also applies to Linux version, very frustrating when you want to control
browser's context menu. I'm writing my mouse gesture extension too, it's impossible
for the script to decide when to suppress context menus, because the decision must be
based on the pointer movements between mousedown and mouseup events. I even tried to
cache the contextmenu event and then dispatch it later, it does trigger the
contextmenu event listener, but doesn't generate the menu.

Yes, it's a problem for mouse stroke extension on Linux. This bug should not be 
Please it's not so much when the context menu is popping up, it's 
that you can't stop it correctly. Please help I would change to chrome if it had a 
mouse gestures.

Comment 8 by, Nov 24 2009

Also a PITA for me, I find gestures are vital for my browsing (actually I only use the 
close tab gesture in reality but I use it for just about every page I visit).
I'm a avid Linux user, have been for many moons, I love mouse gestures in Firefox and 
it's lack of availability in Chrome is the only thing preventing me from using it. My 
job requires using the browser for bout 10 hours a day, so the usability of gestures 
on Linux is paramount to my (and I'm sure many others') use of this otherwise 
excellent browser.
Please dear sweet Google fix this, it's like my fingers have been BROKEN! I need 
gestures back!
with opera on linux, the context menu does not appear until button release.

with firefox on linux, context menu appears on button press. after installing all-in-
one gestures extension, behavior changes and context menu appears on button release. 
even after changing preferences to disable mouse gestures, context menu behavior 
remains altered. only after disabling the extension does context menu appear on 
button press.

so it seems extensions have some way of intercepting the button press event before 
other processing, it would be nice of chromium would support the same.

Hi, rohitbm, could you reopen this issue? Or as tbour said, provide some API or so to 
support the need of mouse gesture? Thanks!
Context menus show on mousedown on OS X in all sane apps. We won't change this.

It sounds like you guys are really looking for a way to suppress the context menu from 
an extension. If you file a bug for that, that's something that might get implemented :-)
This may be the case, but the fact is that the behavior of Chrome on some platforms
(ex: Windows) is different than others (Chromium on Linux). How is this not
considered an issue that should be resolved? Unless of course Chrome and Chromium are
not considered the same product and therefore it is not a reasonable assumption that
they have the same functionality.
In general, we believe people switch apps more often then they switch operating 
systems, hence consistency with the platform is more important than consistency with 
chrome on other platforms. There are many examples for this (default look, keyboard 
shortcuts, spellchecker, etc).
Most all the advanced browsers on Linux support this in some form:

Firefox (and Seamonkey) on Linux = right mouse button gestures w/ addon
Konqueror on Linux = right mouse button gestures w/ plugin
Opera on Linux = right mouse button gestures by default
Midori on Linux = webkit based browser with middle mouse button gesture support

Firefox's handling is by far the most popular, right click and back up with less than 
10pixels of jitter (or whatever) and it gives you the context menu, but if you move 
it beyond the set threshold, it knows to stifle the context menu and instead draw the 
gesture. People can have it both ways, no problem.

Any talk about "keeping behavior as expected by the user on their platform" only 
reinforces the need to support extensions being able to capture right mouse click for 
gesture support, at least on Linux. I also find it hard to believe you are all that 
concerned with keeping the same look and feel of the host operating system when you, 
by default, disable the native window decorations and controls. It's yalls baby do 
with it what you want, just know the option of having mouse gestures is obviously 
possible and the standard is set for it. Best of luck :)

This bug is about OS X, not Linux. See the OS label in the top left corner. As I said 
above, it sounds like the mouse gesture use case might be fixable in another way.
Fair enough:  Issue 30813  requests the ability to suppress context menus. hopefully I 
didn't mess it up.

Comment 19 by Deleted ...@, Jan 19 2010

For Chrome on Linux (Ubuntu 9.10) gestures works fine with extension "Mouse Stroke" if 
middle mouse button is set as trigger (in extension's options). It's not so good as it 
could be (it's annoying after switching from Firefox), but it works at least...
Chromium version 4.0.302.0. 
Smooth Gestures (version 0.9.2) works fine on most web pages on Ubuntu 9.10.
But it still does not work on pages such as "new tab" page, extensions page or history 
In Linux, personally I like global mouse gesture easystroke:

Comment 22 by Deleted ...@, Jan 28 2010

I just don't get it ... maybe the following suggestion is something you can deal 

OnMouseLeftDown( ) {
   // show the context menu instantly
   bMouseLeftDown = TRUE;

OnMouseLeftUp( ) {
   // keep showing the context menu
   bMouseLeftDown = FALSE;

OnMouseMotion( ) {
   if( bMouseLeftDown) {
      if( bHaveGestureExtension) {
         // close the context menu and pass control
         // to the gesture extension

Another point is that gestures replace most/all of the options of the context menu :)

Keep on the good work!!!

Comment 23 by, Feb 8 2010

I can understand why OS integration is important, however if I understand this 
correctly this causes the contextmenu event to be triggered by different mouse events 
depending on the OS, which may break some web pages that rely on it triggering with 
mouseup instead of mousedown, for example.   Perhaps when oncontextmenu is subscribed 
to, the menu behavior can be changed to show on mouse up to avoid such possible 
incompatibility problems with webpages.  With no event listeners it would be safe to 
revert to standard OS behavior.

Comment 24 by Deleted ...@, Mar 12 2010

Being a software developer myself, I can manage to understand the replies from chrome 
developers posted here.

OTOH, if I told my own clients "I'm not very interested in your problem", they would dump me.

As a user, the situation is: Chrome/Mac has no mouse gestures and does not seem close to 
getting them. Dump Chrome. No problem.

(I installed Chrome today: v5.0.307.1, Mac OS X 10.5.8. I liked it a whole lot, but will never use it 
without mouse gestures. End of sad story.)

@bbhdev: actually, while somewhat flaky, smoothgestures (that someone mentioned
earlier) works reasonably well. Doesn't work in incognito mode, but I'll take what I
can get. 

Firefox 3.7 promises a much faster javascript engine, so I think chrome will lose
some of its competitive edge

Comment 26 by, Apr 11 2010

Does anyone know what changes are needed to resolve this issue on Linux? I spent 
a couple of hours looking at the code but didn't find the code that handles the 
mouse down event and shows a context menu. 
I know you have Wont Fix on this issue, but can you please look at Issue #28226 because if that one was fixed it would make this one irreverent. 

Comment 28 Deleted

Now that Smooth Gestures has been exposed as malware, (, that leaves us Linux users once again without a usable Gestures extension. Mouse Stroke is fine on Windows and on those Linux PC's that have a 3 button mouse, but it doesn't help on a 2-button netbook.

Please get your fingers out of your **se and find a solution for this, how hard is it really! I hate the arrogant developer attitude that says "in the name of our ideal XYZ, we won't do ABC even though it makes sense in the real world".

Comment 31 by Deleted ...@, Apr 30 2012

Hacked working version positive feedback -
Project Member

Comment 32 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
 Issue 800685  has been merged into this issue.

Sign in to add a comment