User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5
When you go to google maps on firefox 2 and right click on the map, you will see a context menu that allows you to "get directions to here" or "get directions from here" In Firefox 3 Beta, it doesn't show up anymore. I have tested this on Windows and OSX so I'm guessing it's the same for all builds.
Reproducible: Always
Steps to Reproduce:
1. Go to http://maps.google.com/
2. Right click on the map
3. Nothing happens!
Actual Results:
Nothing happened
Expected Results:
A context menu should appear saying "Directions to here", "Directions from here", "Zoom out", "Zoom in", and "Center map here".

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008040300 Minefield/3.0pre
This works fine here unless I have changed the advanced javascript setting to disable or replace the context menu, so with this setting unchecked I see on mouse down Google's context menu and on mouse up it is obscured by Firefox's own context menu.
I think this bug is invalid.

(In reply to comment #1)
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008040300
> Minefield/3.0pre
>
> This works fine here unless I have changed the advanced javascript setting to
> disable or replace the context menu, so with this setting unchecked I see on
> mouse down Google's context menu and on mouse up it is obscured by Firefox's
> own context menu.
> I think this bug is invalid.
>
I tested it and it does seem to work in Windows but it still doesn't work in OS X though. I will test the Linux version when I get home.
Joe

I do not currently have a mouse, so I can't test right-clicking with one.
Ctrl+click correctly brings up the menu.
If I right click using my touchpad (by tapping 2 fingers at once on the touchpad), nothing happens.

(In reply to comment #11)
> What, precisely, does "right click via touchpad" mean?
>
> Does this problem also happen with an ordinary right click (as originally
> reported)?
>
> Does it happen with a ctrl-click?
On the unibody Macbook Pros and Macbooks it's placing two separated fingers on the touch pad and pressing the entire pad down as one button. On the older generation Macbook Pro's and Macbooks, it's placing two separated fingers on the touch pad and pressing the touch pad button.
ctrl+click works properly.

(In reply to comment #13)
> On the unibody Macbook Pros and Macbooks it's placing two separated fingers on
> the touch pad and pressing the entire pad down as one button. On the older
> generation Macbook Pro's and Macbooks, it's placing two separated fingers on
> the touch pad and pressing the touch pad button.
>
> ctrl+click works properly.
Using an external mouse (in my case MS IntelliMouse optical) and doing a right click doesn't work too. I have to do Ctrl+Left click to bring up the context menu.

This bug has been around for a year?? It does not seem that if should be that difficult to fix. There appear to be many users experiencing the same problem. I and another developer discovered it after spending too much time thinking it was our issue. Why not get this fixed?? To summarize, on OSX, right click will generate Google Maps Contextual menu once then nothing on subsequent right clicks. Reloading the page will once again allow to right click and get Google Maps contextual menu. Control-Click works correctly every time. Same error still occurs on latest FF 3.5 nightly build.

Thanks but we don't need any more confirmations. The steps and the reason why it happens is clear. Developers need time to fix such an issue. And in the last month (since my investigation) there had to be fixed bugs with higher priority so we can ship Firefox 3.5. Please be gentle. I'll ask for blocking1.9.2 so we don't loose this regression.

The control-clic do work on firefox 3.0 & 3.5. However, a new regression makes impossible to select one of the item in the pop-up menu !
To me, it seems that 3.6 is far to be ready in its Mac flavor, unfortunalety.

I want to say that finally, things are not that bad: I have found a way to use the contextual menu in Google Maps. Control-Clic, select an option but clic on it without the control key pressed any more ! This way it works, but it would be one thousand better if the right clic was functional.
Bug 537269 is a lot more problematic as it seems that no work around exists.

As Firefox 4 is late, would be possible to include this bug as blocking Gecko 2.0 ? I know this bug is not a major one, but as the competition from Chrome or Safari are very strong, it should be better to have a fully functionnal browser from Mozilla I think.
Have a good day.

As beta 12 did not bring any improvment, I was wondering if every website using the right clic were not functionning. Actually, this is not the case. The Zimbra webmail allows a right clic to bring customized menus, and it works perfectly on the Firefox 4 beta 12.
I don't know if this could help, but I guess this is track to follow.
Exemple of URL working: http://zimbra.free.fr (but you have to be a Free client, Free being 2nd ISP in France)
As a reminder: Google or Bing maps do not work (for the right clic I mean).

I know our app and Google maps both have this bug, and we're both using jQuery. I'm wondering if there's an issue in jQuery? Just something to possibly look in to.
I tested on Zimbra too and they definitely got their right-click menus working. So there must be a work around. Does Zimbra use jQuery? I'm not that familiar with it.

To get the context menu you need to go to Tools -> Options -> Content and there do 2 things:
1. check the checkbox "Enable JavaScript"
2. click "Advanced..." button at right of that checkbox and there check the bottom checkbox

(In reply to comment #31)
> To get the context menu you need to go to Tools -> Options -> Content and there
> do 2 things:
> 1. check the checkbox "Enable JavaScript"
> 2. click "Advanced..." button at right of that checkbox and there check the
> bottom checkbox
Even with this set, the problem still occurs.
Please do not comment with any more Steps To Reproduce, we already have enough :P (comment 15)
If you have advice for solving this wrt Cocoa widgets, feel free to join in :)

Oops, didn't see that it is a MacOS bug. I'm on Windows and earlier I've experienced that issue with google maps for example. Only some time after I've found the solution which I wrote in the previous comment. So now I don't experience that bug anymore and thought that same steps might also help you.
And sorry, I don't even know what is Cocoa widgets.

Created attachment 534163[details][diff][review]
Remove safety check before bringing up menu.
After looking at the problem, it turns out that |menuforEvent:| (in cocoa/nsChildView) is not being called when the mouse is being right-clicked. (when the click is made by a control+click, |menuForEvent:| is actually called by the super, and it calls |mouseDown:|.)
|menuForEvent:| is not being called because |rightMouseDown| adds a safety check to DispatchWindowEvent (presumably to avoid double handling the event).
This patch removes that safety check.
First I tried understanding why the status was being set but after this proved useless, I removed the check and looked for its origin. Turns out it has been there from the start:
https://github.com/jrmuizel/mozilla-cvs-history/commit/720831252bfefb1250596b5c68d45a59dde1e254#L4R2500
Furthermore, I looked at code in the windows widget and it seems like they call DispatchWindowEvent (a similar version) without worrying about the result.
Of course, I tested the code on Google Maps, and it provides the expected behaviour. I didn't stress test it on other cases though.

What a good news ! Will it be part of FF5 or FF6 ? Is there a way I can help (some testing for exemple, but if yes, please tell me with which version).
Thanks for your job however, it is so frustrating not being able to your the mouse in Google Maps.

I found the relevant blob in the Linux widget code:
http://mxr.mozilla.org/mozilla-central/source/widget/src/gtk2/nsWindow.cpp#2848
The same status is returned when right-clicking on Google Maps (nsEventStatus_eConsumeNoDefault) but the code ignores it and still sends a context menu event. Based on that, it looks like we should be fine doing the same.
(In reply to comment #35)
> What a good news ! Will it be part of FF5 or FF6 ? Is there a way I can help
> (some testing for exemple, but if yes, please tell me with which version).
> Thanks for your job however, it is so frustrating not being able to your the
> mouse in Google Maps.
At this point, we can't really evaluate whether it will be backported to FF4/5 or if it will go in FF6. Assuming that this patch passes review, we need to determine how safe it would be (as it may cause more regressions).

Comment on attachment 534163[details][diff][review]
Remove safety check before bringing up menu.
This looks fine to me.
We've always had problems getting getting reliable information about
whether or not a given event was handled, and I suppose that's
ultimately the cause of this bug -- Google Maps must (presumably) be
telling us that the right-click wasn't handled.
But Mehdi's found that other platforms don't check whether or not a
right-click was handled before bringing up a context menu. Even in
Cocoa widgets, no other mouse event gets checked for whether or not
Gecko has handled it. And (as Mehdi pointed out in comment #34) the
original reason for this check is lost in the mists of time.
I do have one nit to pick: The "let the superview do context menu
stuff" comment is wrong. It should read "Let the superclass do the
context menu stuff".
Thanks, Mehdi, for fixing this longstanding bug!

Comment 39Smokey Ardisson (offline for a while; not following bugs - do not email)
2011-06-01 14:20:55 PDT

Thanks, Smokey!
I'd actually used http://bonsai.mozilla.org/ (and CVS Blame) to find
where bryner landed changes from CHIMERA_M1_0_1_BRANCH on the trunk.
But I neglected to track down those changes in CHIMERA_M1_0_1_BRANCH.
It's still not clear, though, why the "handled" check on the
right-mouse-down was added.
The only context menu bug addressed by sfraser's patch is bug 158345.
But I don't see how this bug's check (i.e. the one Mehdi's patch
removes) could have fixed that bug. And in any case removing the
check doesn't regress bug 158345.
Also, ctrl-click has for a long time not had the check, and I'm
unaware of any outstanding problems using ctrl-click.
So I still think Mehdi's patch is the right way to fix this bug.

(In reply to comment #38)
> Comment on attachment 534163[details][diff][review] [review]
> Remove safety check before bringing up menu.
>
> This looks fine to me.
>
> We've always had problems getting getting reliable information about
> whether or not a given event was handled, and I suppose that's
> ultimately the cause of this bug -- Google Maps must (presumably) be
> telling us that the right-click wasn't handled.
>
> But Mehdi's found that other platforms don't check whether or not a
> right-click was handled before bringing up a context menu. Even in
> Cocoa widgets, no other mouse event gets checked for whether or not
> Gecko has handled it. And (as Mehdi pointed out in comment #34) the
> original reason for this check is lost in the mists of time.
>
> I do have one nit to pick: The "let the superview do context menu
> stuff" comment is wrong. It should read "Let the superclass do the
> context menu stuff".
>
> Thanks, Mehdi, for fixing this longstanding bug!
Awesome!
How safe do you think this is to backport? It looks like the Linux code does the same thing, so we shouldn't break any more pages but I'm not sure if the Mac code path would be much different.

> How safe do you think this is to backport?
It should be quite safe -- the code to generate context menus hasn't
changed in the last few years. But we should probably let this patch
bake on the trunk for a while before trying to backport it.

If the patch author believes this is suitable for landing in the Aurora channel, then he could set the approval-mozilla-aurora? flag to request inclusion in Firefox 6. But since this bug has been around since Firefox 3.0, it may not be urgent enough to push to Aurora at this point.
Firefox 7 is scheduled to be released just six weeks after Firefox 6.

Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0a1) Gecko/20110611 Firefox/7.0a1
IMO it's nothing critical which should be pushed to aurora. Firefox 7 will be released in about 6 weeks so I'm sure you can wait for it or use an aurora build after the next merge has happened in the next days.

Note

You need to
log in
before you can comment on or make changes to this bug.