28604 - [DOM] Context menu should wait for onclick / onmousedown handler

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Taras Tielkes]

Using right-mouse-button to access the pup-up context menu will fire an onclick 
event.

I have a table in a page that responds to mouse clicks.(By giving a 
MessageBox/JavaScript alert() ). Because of this behaviour the user can't 
launch the context menu.

Comment 1

[Taras Tielkes]

I don't know what's in the specs (if any) about this, but I expect a RMB click 
to have no effect whatsoever on the document viewed. (on Windows at least)

Comment 2

[Daniel Bratell]

Could you please give a url to a page where one can see this problem. That would 
help debugging and confirming the bug.

Comment 3

[Taras Tielkes]

Well, I am not sure to call it a bug. But it can be annoying sometimes.

Just make a big table with an onclick handler. Hit Right-MB while over the 
table (like you're planning to select Reload on the context pop-up menu) and 
the "onclick" handler will run.

Comment 4

[Richard Zach]

This is probably DOM0, so CC: vidur.  True enough, a right click fires onclick. 
The which property indicates which mouse button was pressed (1=left,3=right). 
In NS 4.7, a right click doesn't fire an onclick.  My hunch is that this is a
bug in NS 4.7, and has since been fixed.  After all, it is probably desireable
to allow the web page to capture right-clicks, just as it can capture shift- and
alt-clicks.  So maybe the context menu should wait for the onclick handler. 
Specifically, the context menu should only come up if the onclick handler
returns true.  Attaching a testcase.

Comment 5

[Richard Zach]

Attachment: Testcase

Comment 6

[Richard Zach]

In the testcase, try click, shift-click, and right-click on the link.

Changing summary, cc: self.

Comment 7

[ekrock's old account (dead)]

Marking testcase and m17.

Comment 8

[Taras Tielkes]

The solution that Richard suggests would also allow for a custom context menu 
(using a positioned DIV).

If an onclick or onmousedown handler returns false, no further action 
(including drawing the Mozilla context menu) should be taken.

Comment 9

[joki (gone)]

Updating Milestone to M18.

Comment 10

[joki (gone)]

Adding [DOM] prefix

Comment 11

[ckritzer (gone)]

Mass update:  changing qacontact to [e-mail]

Comment 12

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

If you attach an onlick handler with the onclick attribute, how can you tell 
which button was pressed? <p onclick="alert('Help! Which button?')">

If we'd allow content creators to override context menu, would this create a 
security risk?

Comment 13

[Taras Tielkes]

Heikki, the custom context menu should be painted by the page itself, so it 
won't have the exact look and feel of the real one.

IE5 exposes the "oncontextmenu" event for catching "right-clicks".

This DOM2 code works:
---------------------------------------------
<p onclick="alert(event.button)">
---------------------------------------------
for all three buttons on Win32.(Except of course with button 3 (=right), the 
Mozilla context menu pops up before the JavaScript event handler)

Comment 14

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

In Mozilla everything is done by the same layout. I am not sure if there is some 
special stuff to get the look and feel of Mozilla menus that is unavailable in 
normal content. If it is all the same stuff you could fool the user doing 
something stupid/potentially dangerous by creating a context menu that looks 
exactly like the real one but does different things. In principle I think it 
would be great to be able to override the default context menu, though.

Comment 15

[Taras Tielkes]

Heikki, the custom menu would only work above the rendered HTML page, not in 
the rest of the browser. The options that are available for links, images and 
other HTML content could be "mimicked", but in what way could this become a 
risk? Opening new browser windows (available since NS 2.0) can also be used 
to "fake" pop-up dialogs, but can any real harm come from this?

Comment 16

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

I just realized there is a workaround, although not perfect. Maybe you would 
want to give it a try...

function mymenu() {
	document.getElementById("id1").click();//Prevent context menu
	// If you had focus in some special element that is lost so you would
	// need to focus programmatically back. That is not perfect, however.
	alert("This should be my own context menu");
}

<!-- Make this a separate element. If you want to have context menu for
  INPUT element and you call the click on that element, nothing happens -->
<INPUT id="id1" type="hidden">

<p onclick="if(event.button==3)mymenu()">Right-click me to get my own context 
menu</p>

Comment 17

[Taras Tielkes]

Heikki, I don't see the context menu disappear when I try your example. 
Actually, it *does* disappear, but only when I call 'alert()'. When the call to 
alert is commented out, the context menu still shows. Perhaps I misunderstood, 
here the very short file I tried:
---------------------------------------------
<HTML>
<BODY>
<INPUT id="id1" type="hidden">
<p onclick="if(event.button==3) document.getElementById("id1").click();">Right-
click me!</p>
</BODY>
</HTML>

Comment 18

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

Strange, I tried replacing the alert with dump and it still seemed to work for 
me. The idea in this workaround obviously was to dismiss the context menu like 
you normally do: click somewhere else. In this case I was hoping it would be 
dismissed before it is even displayed. Oh well, have to think some more...

Comment 19

[Taras Tielkes]

Hi, Heikki, could you exmplain what you mean by "dump"?

Is it that hard to cancel the default Mozilla event handler when the ECMAScript 
handler for the event returns false (cancels the event)?

Comment 20

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

alert('foo'); -> dump('foo');

In debug builds at least you can see the "dumped" content in the console window.

Regarding if it is difficult to cancel the event: no, I do not think so, it is 
used all over the place as far as I can tell. The problem with context menu just 
seems to be that the context menu is launched before/regardless of the handler 
return value.

Comment 21

[Taras Tielkes]

Is it possible to move the code that invokes the context menu after the 
ECMAScript event system, or would that mean a big rewrite?

Comment 22

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

I do not know how big a change it would be without looking at the code. In any 
case I am kind of doubtful I would have time for this. Unless you can think of 
compelling arguments why you would want this to be fixed for nsbeta3, I think I 
will be marking this with milestone Future.

Comment 23

[Taras Tielkes]

It's very important for building nice DHTML UIs ;-)

Just think of all the places context menus are used in real applications...
But I assume this one pales compared to all the other nsbeta3 bugs.

Comment 24

[Taras Tielkes]

OTOH, this bug kindof falls in the "basic event handling" category. ;-)
The way that both the context menu and the JavaScript handler fire is kind of 
messy.

Comment 25

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

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration.

Comment 26

[Loco]

Updating QA Contact.

Comment 27

[Asa Dotzler [:asa]]

*** Bug 60955 has been marked as a duplicate of this bug. ***

Comment 28

[Matthias Versen [:Matti]]

*** Bug 60955 has been marked as a duplicate of this bug. ***

Comment 29

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 30

[Jacob Kjome]

I have a problem with the onclick even being triggered with a right click.

I have code that looks like this:  
<a href="http://www.visi.com/~hoju/humor.html" onclick="newWin(this.href);
return false;">humor links</a>

I use this to avoid using the non-existent HTML Strict attribute "target".

Both IE4+ and Netscape4.x (I think) ignore the onlick event on a right click. 
However, if you right click the link in Mozilla, the onclick gets triggered and
a new window opens.

This behavior can be seen on most links on the following page:

http://www.visi.com/~hoju/humor.html

BTW, avoid mousing over the Simpsons Archive link.  That, devilishly, will open
up a new window simply on the mouseover.  Also, the topmost don't open in a new
window, but all others below the Simpsons archive link will display this behavior.

I spoke with timeless about this on #mozillazine and he quickly stated that the
onclick should NOT be triggered by the right click event which seems to
contradict some of the conversation in this bug (if I've interpereted it correctly).

Am I way off here?  Is this going to get fixed?

Jake

Comment 31

[Jesse Ruderman]

See also bug 72084, "There is no way to disable the context menu upon right-
click".

Comment 32

[Taras Tielkes]

The new "oncontextmenu" functionality implemented by David Hyatt fixes exactly 
what what this bug is about, except only for that specific event. (Btw, I hope 
oncontextmenu will be included in a future dom revision, since both Mozilla and 
IE implement it.)

See the Mozilla DOM newsgroup for a sample.

The question remains: should the context menu be cancellable via the onclick 
handler? In other words: exactly what default action should event.preventDefault
() cancel. It seems to me that with oncontextmenu implemented, this doesn't 
really belong in the onlick event. (Context menu is not a default action of the 
click event per se.)

AFAIK, IE5+ takes the same stance:
1) "oncontextmenu" can be used to cancel the menu.
2) there is no relation between the "onclick" event and the context menu.

Comment 33

[Ben Bucksch (:BenB)]

What does the oncontextmenu handler do  and allow exactly?

IMO, it is none of the business of a webpage to mess with context menus in any
way. Sometimes (e.g. after a window.open or when I minimize the normal chorme),
the context menu is my only way to interact with the app. E.g. to access "View
Source" or to specify how to open a link or anything. A webpage must not be
allowed to interfere with my ability to do so.

I have seen pages that tried to prevent me from looking at the source. This must
not happen.

In this case, a don't care about any W3C spec. This is basic usability. At the
very least, I must have the option (with UI) to disallow such malicious
behaviour of webpages. Everything else is IMO a serious bug.

Comment 34

[Taras Tielkes]

Ben, please stay on topic for this bug.

Check Hyatt's post in the DOM group first, and then comment there.

Comment 35

[Taras Tielkes]

Inserting my comments from 71705 here:
--------------------------------------
Bug 28604 is about the need to disable the context menu. This is useful in some 
special cases. In most cases this is for specific elements. Anyway, that need 
is addressed by the "oncontextmenu" event.

This bug is more important, IMO. Classis browsers always fired the "click" 
event for a left-button press. It seems that the DOM2+ specs suggest 
(not "imply" IIRC - button information is 'accesable' from mouse event 
handlers) that every click, left, middle or right, fires the "onclick" event.

My suggestion:
1) Make "onclick" only work for LMB clicks (or whatever equivalent on other 
platforms).
2) Make the other mouseclick events (mousedown + mouseup) work on all button 
clicks. That way, the functionality is still there if desired.
3) Suggest this change to the DOM spec.

Comment 36

[Ben Bucksch (:BenB)]

> Ben, please stay on topic for this bug.

huh? You said:

> The new "oncontextmenu" functionality implemented by David Hyatt fixes exactly
> what what this bug is about

and

> Bug 28604 is about the need to disable the context menu.

I just suggested WONTFIX. Why is that offtopic?

> Check Hyatt's post in the DOM group first, and then comment there.

I didn't know of such a post. Thanks for the hint.

Comment 37

[Taras Tielkes]

Ben,

My original wish, and the reason why I did submit this bug a long time ago, was 
to use a custom conext menu, by drawing a absolutely positioned DIV with a 1-
row table.
Since at that time Mozilla didn't have a "conextmenu" event, I thought I could 
use the DOM2 mouse event functionality as implemented by Mozilla. This almost 
worked: I could catch the LMB click, but I couldn't prevent the default context 
menu from appearing simultaneously. So: 
*** This bug was a request to make the appearance of the context menu after 
a "click" even cancellable through event.preventDefault() *** 

A side effect of Mozilla's DOM2 mouse event implementation is that thousands of 
pages using the classic "onclick" event do some unexpected stuff when you right-
click:
1) There is a reaction from the page JavaScript, something the author and the 
user didn't expect.
2) Even though (1) happens, the context menu *also* appears.

A number of bugs about exactly these two related problems were marked dupes of 
this one.(incorrectly). Bug 71705 is the right one for that.

Now, what needs to be done (IMHO):
1) This bug can be marked FIXED, since the "contextmenu" functionality 
impemented by Hyatt solves this bug in a more clean, and IE5 compatible way.
To be exact, the fixing of bug 72084 fixes his one.

2) Bug 71705 needs to be fixed by making "onclick" only fire for the 
default "click" button (Left on Win32). This is the only reasonable solution, 
since the current behaviour breaks a LOT of pages. Note that this is also the 
behaviour of Internet Explorer.

Comment 38

[Madhur Bhatia]

QA contact updated

Comment 39

[Pham]

.

Comment 40

[Jonathan Watt [:jwatt]]

As originally reported ("using right-mouse-button to access the pup-up context menu will fire an onclick event") this bug no longer exists. Marking WORKSFORME.