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.

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)

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

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.

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.

In the testcase, try click, shift-click, and right-click on the link. Changing summary, cc: self.

Marking testcase and m17.

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.

Updating Milestone to M18.

Adding [DOM] prefix

Mass update: changing qacontact to ckritzer@netscape.com

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?

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)

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.

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?

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>

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>

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...

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)?

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.

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

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.

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.

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.

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.

Updating QA Contact.

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

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

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

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

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

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.

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.

Ben, please stay on topic for this bug. Check Hyatt's post in the DOM group first, and then comment there.

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.

> 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.

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.

QA contact updated

.

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.