230281 - Contextmenu blocking doesn't work. Right Click always opens the standard Context menu.

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Martin Heidegger]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030306 Camino/0.7
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030306 Camino/0.7

IE and Mozilla support Context menu blocking with javascript. Camino does
handles this wrong 

Reproducible: Always

Steps to Reproduce:

Actual Results:  
Context menu appears next to special menu.

Expected Results:  
Hidden the Context Menu and placed the specialized menu correctly.

Comment 1

[Mike Pinkerton (not reading bugmail)]

we're told to display the context menu from gecko. is this a regression in the
embedding layer? does it still work in winEmbed? Adam?

Comment 2

[Bruce Davidson]

This works in latest Mozilla builds on MacOS X (2004011305), but in Camino I get
both the JavaScript context menu and Camino's normal context menu. Dupe search
shows no similar bugs anywhere, so confirming. Will investigate a bit further.

Mike, how would I set about telling if this is a regression in "WinEmbed"?

Comment 3

[Adam Lock]

winEmbed doesn't display popup menus, but mfcEmbed does. 

I can reproduce the behaviour there.

I can't reproduce it if I load up some chrome, e.g.
chrome://navigator/content/navigator.xul, load "www.mozilla.org" into that and
right mouse on the content area.

Comment 4

[Mike Pinkerton (not reading bugmail)]

go to a windows machine and run winEmbed :)

Comment 5

[Mike Pinkerton (not reading bugmail)]

adam, so that says to me it's a bug in the embedding layer, right?

Comment 6

[Adam Lock]

Or in the DOM.

I know I haven't touched the embedding layer since July. The place which adds
the listener is here:

http://lxr.mozilla.org/seamonkey/source/embedding/browser/webBrowser/nsDocShellTreeOwner.cpp#864

The actual contextMenu event handler impl is here:

http://lxr.mozilla.org/seamonkey/source/embedding/browser/webBrowser/nsDocShellTreeOwner.cpp#1541

The code does call nsIDOMEvent::preventDefault() so perhaps that has broken, or
maybe it should be calling nsIDOMEvent::stopPropogation() too. It would be worth
CC'ing some of the DOM folks.

Comment 7

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I bumbed into this a couple of weeks back as well. preventDefault did not seem
to do anything, but return false prevented the context menu from appearing (in
the context menu or click handler function).

Comment 8

[S Woodside]

So we're going to change the product to Mozilla right?

Comment 9

[Mike Pinkerton (not reading bugmail)]

over to browser

Comment 10

[Boris Zbarsky [:bzbarsky]]

So what code in Mozilla handles opening the context menu? Is it the
http://lxr.mozilla.org/seamonkey/source/embedding/browser/webBrowser/nsDocShellTreeOwner.cpp
code?  Or not?

The embedding code is never checking whether the event has been consumed;
perhaps that's the issue?

Comment 11

[Johnny Stenback (:jst)]

Attachment: Untested shot in the dark

Something like this then maybe? Someone care to test this?

Comment 12

[Adam Lock]

Comment on attachment 141006 [details] [diff] [review]
Untested shot in the dark

isDefaultPrevented should probably be initialised to PR_TRUE but makes sense
otherwise, should probably be tested in mfcembed though.

r=adamlock

Comment 13

[Boris Zbarsky [:bzbarsky]]

Alexandre, do you happen to have a build you could give that patch a spin in?

Comment 14

[Alexandre Trémon]

I tested this in mfcEmbed.

This patch is fine.
Just misses:

#include "nsIDOMNSUIEvent.h"

Comment 15

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 141006 [details] [diff] [review]
Untested shot in the dark

sr=bzbarsky, with Adam's comment.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Actually, PR_FALSE is a better default... Checked in with that and the header
include.