Open Bug 248169 Opened 20 years ago Updated 2 years ago

Firefox's own context menu is shown in spite of my own oncontextmenu handler

Categories

(Firefox :: Menus, defect)

Product:
Firefox
Component:
Menus
Platform:
PowerPC
macOS
Type:
defect

Tracking

()

People

(Reporter: carls, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/0.9/firefox-0.9-mac.dmg.gz

Even though my oncontextmenu handler returns false, Firefox still shows it's own
context menu on top of mine. The context menu code works fine on Mozilla 1.7 for
MacOSX and Firebird 0.7 + Firefox 0.9 for Win32.

Reproducible: Always
Steps to Reproduce:
1. Go to http://gonzo.1av10.nu/working/cm.html
2. Right click on one of the links

Actual Results:  
Firefox's contextmenu shows up on top of mine

Expected Results:  
My own contextmenu should show up instead of Firefox's
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
works on windows
This works fine for me on Firefox 0.9 for MacOSX if I do a right mouse click or
Ctrl+Click.  If I do a click-hold, then the mozilla context menu appears.
(In reply to comment #2)
> This works fine for me on Firefox 0.9 for MacOSX if I do a right mouse click or
> Ctrl+Click.  If I do a click-hold, then the mozilla context menu appears.

In Mozilla 1.7 / Firefox 0.9, we have a new way to block these menus : see bug
86193. The default setting for dom.event.contextmenu.enabled is true through,
which allows this menu to be seen.

When dom.event.contextmenu.enabled is false, then we can see this beviour : both
menus will pop up, the Mozilla one on top.

Is this bug a regression of bug 86193, or is this bug 186356 ?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter, what is your current value of dom.event.contextmenu.enabled ? Type
"about:config" in the locationbar, then you can see all the current settings.
(In reply to comment #4)
> Reporter, what is your current value of dom.event.contextmenu.enabled ? Type
> "about:config" in the locationbar, then you can see all the current settings.

Hi, dom.event.contextmenu.enabled is set to "true".

Just called in to say that this still seems valid for me in Firefox 1.0.3 on
GNU/Linux (works on Win32 though).

Originally discovered it during some JS experimenting of my own, but it holds
for this reporters test case.
For the sake of consistency, please dont let this bug go free to the firefox 
1.1. I believe "dom.event.contextmenu.enabled" thing was not troughly tested on 
all platforms, there are platform specific regressions non-windows machines.

note: whose idea was it anyways ;).
Flags: blocking-aviary1.1?
Patch presented in bug 72084 may require a recheck.  Boris, I saw your comments 
on bug 72084. you may want to take a look at this.
I have no way to reproduce or debug this, offhand... Someone with a mac will
have to take a look.


But according to comment #6, this bug also exists on Linux.
With what steps to reproduce?  The testcase works fine in a current trunk (not
1.0.3) Linux build over here.
Carl, could you check the latest nightly to see if your contextmenu works on 
MaxOS X?
(In reply to comment #12)
> Carl, could you check the latest nightly to see if your contextmenu works on 
> MaxOS X?

Unfortunately, the bug was discovered and reported using a friends Powerbook.
I'm on Win32 right now.
The only bug I do see here (using today's trunk build) is what javier descirbed
in comment 2. I guess the click & hold code simply ignores
document.oncontextmenu from non-trusted events?.. ccing pinkerton.
More wood for the click'n'hold fire! Josh, we need a decision on this ASAP.
Flags: blocking-aviary1.1? → blocking1.8b4?
dom.event.contextmenu.enabled to true (default)

Normal contextual behaviour is retained (right-click or control-click), however, the problem remains 
with click-hold and introduces somewhat confusing behaviour like bug 1102330. I'm still a little 
confused as to why click-hold functionality is within Firefox at all. The contextual menu has been 
around for mac users for a very, very long time now and i haven't come across another application that 
makes use of this functionality (i'm only too happy to be corrected).

OS X 10.4.2 Deer Park Alpha 2

It might also be worth mentioning that the logic of contextual menu use in this situation also provides a 
slight problem with this function. It's difficult to know if most users do this, but if a context menu is in 
use and the user wishes to cancel the procedure or get out of the context menu, many will try and click 
or right-click somewhere else within the window to cancel the context menu function. Thus, if you 
right-click out of the dom contextual menu you end up with the Firefox contextual menu, necessitating 
another click to get out of that contextual menu.

Another thing i just noticed in the given examples, if right-clicking whilst navigating in some parts of 
the contextual menu, Firefox will perform a Save As instruction.
This bug happens in Camino too.
Simon - can you take a look at this one? Do you think it needs to block the Deer
Park beta release? Thanks.
Assignee: firefox → sfraser_bugs
Flags: blocking1.8b4? → blocking1.8b4-
QA Contact: bugzilla → menus
I got interested in this bug after someone, using on Mac OS X an application I
developed that uses its own context menu, observed the same problem.

This person recently reported that the problem had disappeared after
uninstalling Firefox extension "All-in-One Gestures".

I then tried this extension in Firefox 1.0.6 on Windows ME, and found that it
was also causing erratic event handling of my context menu (although in a
different way, on close rather than open).

Perhaps the "All-in-One Gestures" extension is doing things that Firefox should
protect itself against.
Hmm, verified on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10). With
All-in-One-gestures, test case failed. After uninstalling, it works. I think I
used that the first time I verified the bug, also...

Aww. Now I can't use mouse gestures any more...

O, i'm guessing at the extension architecture here, but how about, instead of
letting All-in-One-gestures (or any extension) catch the click, and then open
the context menu (which I assumed happened), how about letting it catch the
click, and then, if it's not a mouse gesture, "return" the click to Mozilla?
That would seem like a cleaner solution....
Assignee: sfraser_bugs → nobody
This bug is also present when using Optimoz's Mouse Gestures extension.

It's been reported and is marked as invalid:
http://bugzilla.mozdev.org/show_bug.cgi?id=11760

This should probably moved to the extensions' bug trackers.
Is there a way we can provide hooks for extensions to behave better here (per comment 20)?  If not, this is invalid...
(In reply to comment #22)
> Is there a way we can provide hooks for extensions to behave better here (per
> comment 20)?  If not, this is invalid...

I don't think that "hooks" are needed. Simply provide a way to show context
menus on "mouseup". (e.g by pref)

Gesture extensions only have problems with systems with context menus on 
"mousedown". Under Windows (a "context-on-up-system") there are no such problems.

By design Mouse Gestures need a gap before the menu is shown. And all
extensions dealing with this problem (like MozGest on Linux) are using more than
wild hacks to suppress the menu on mousedown and showing it on mouseup.
> Simply provide a way to show context menus on "mouseup"

That would more or less violate platform convention, which is not something to do lightly.

In any case, that's not a "Firefox" change; it'd need to be made in the GTK widget code in Gecko.
(In reply to comment #24)
> 
> That would more or less violate platform convention, which is not something to
> do lightly.
Sure. But Mouse Gestures will violate the convention anyway.
And I hope that there will be a way to violate the convention that does not
totally suck. The "context-on-up-by-pref" would be awesome, altough I understand
that it violates the convention on most systems, it would be imho the best solution.

Current situation:
- context menus are prevented from showing on mousedown.
- weird hacks (with timeouts etc.) to get the rigth context popup
- on mouseup try to show the right context menu and try to make sure that
  spellchecking is not broken. 
  (popupBoxObject.showPopup() for 1.8.x and openPopupAtScreen() for 1.9)

Proposed solution:
- give extensions the opportunity to enable "context-on-up", because they
  would do it anyway. That would enable extensions to simply listen to 
  "oncontextmenu" and if there was a gesture "e.preventDefault()" will be
  called. Without a gesture, no action will take place like it is possible
  under Windows. 
> 
> In any case, that's not a "Firefox" change; it'd need to be made in the GTK
> widget code in Gecko.
> 
Sure. And I understand when this nice "hook" will not be implemented.

BTW:
I think that Opera currently violates the convention the same way...

This is currently lacking a test-case, is anyone here able to reproduce or tell if current version is still affected?
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.