Reproduction: 1. visit <http://freshmeat.net/projects/gnoise/> 2. Right-click on screenshot to open context menu. Actual result: Window and context menu opens Expected result: Only context menu opens Additional comments: - If I do a right-click, I intentionally didn't mean to do a normal click. - Can also be seen on the advertizing table background at the Google result pages. Right-click on the green area (e.g. to go "Back"). - Highly irritating. Very visible.

Over to event handling

I think, I saw this in 0.6 already.

I hesitate to mark it as a duplicate of bug 30881, since it was fixed at one point or another. Perhaps marking it as a duplicate and reopening the original wouldn't be a bad idea.

Might also be related to bug 63073. FWIW, th emore I think about it, the more I think this should be marked as a duplicate of bug 30881, with the original reopened.

Right click is supposed to fire onclick. What's the issue?

Says who? The HTML 4 specs just says "The onclick event occurs when the pointing device button is clicked over an element.". If I say "Click on button Stop", do you right-click? Since there is no onlelftclick helandler or similar, I can only assume, the author of the spec meant the ordinary left-click (primary mouse button click, to be precise). Anyway, I don't want any untrusted script to ever override right-click. This is sometimes used to obfuscate the source (disable menu and right-click). Please give me in any case the option to disallow that.

> What's the issue? To answer this without ambiguity: See reproduction. The result is obviously not what I, the user, expected. And this is true in almost all cases. Why *should* it trigger onclick? leftclick != rightclick.

Left click != right click, sure, but that doesn't mean onclick == left click necessarily...If it didn't specify it, we'd still want to include right and middle clicks, since there's no real reason to assume any button. But that's not an issue, since DOM2 *does* pretty much specify it; mouse events have a button property which is equal to an integer that corresponds to each mouse button. Read up at http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events- eventgroupings-mouseevents. I agree that if we keep right click firing onclick (it seems that IE doesn't), there should be a way to disable it for annoying websites.

methinks this bug won't get fixed for 0.8. renominating.

just my $0.00000002M... If you read most software manuals, you will probably see references to clicking and right-clicking (yeah, like anyone here ever read a manual:)). To some extent, at least, clicking *does* mean left-clicking simply by convention-it's implied. DOM2, blah, blah, when Mozilla has support for it, we can come back to this argument, but for now the right click has a function, and it is a contextual menu. Having it also trigger an onClick for any reason interrupts its primary function, and is thus undesirable-at least for now.

> DOM2, blah, blah, when Mozilla has support for it, we can come back to this > argument This seems like a Catch-22. How can Mozilla support DOM2 if it doesn't follow the language's spec?

I'm not going to mark this as a dupe of 28604 but I will mark it related to it. The hard fact is that the web page is wrong from DOM 2 standards. We've been discussing how to deal with this for compatibility with older pages. We think we might tie into the 'quirks' mode setting which we use for older pages. We may still do that but unfortunately for this page they are using up to date DTD links so they are defining themselves to be up to date. 'quirks' mode would therefore be turned off. I'm happy to keep this bug open to discuss possible alternatives for dealing with this but I'm moving the milestone out. Also replaced the 'regression' keyword with '4xp' which is more appropriate to the bug since mozilla has always worked like this so its not a regression.

> The hard fact is that the web page is wrong from DOM 2 standards I don't know the DOM2 spec, but from the HTML spec, the page is completely OK. I argue that "click" = left-click, if nothing suggests the opposite. > I'm happy to keep this bug open to discuss possible alternatives for dealing > with this Why can't you just treat HTML's "onclick=" as meaning left-click only? Does the DOM2 spec conflict with this in a non-resolveable way? Again, in *any* case, give an option to disable that. Webpages should *not* (not even with DOM2) be allowed to change right-click, because I need it to access the context menu. Overriding this completely cripples my ability to use the browser. I cannot tell you what to work on, but this isn't something to Future, IMO. At least not the pref I described.

One example, where this bug matters: I want to copy the URL of a link, but I do not want to visit it, beacuse I don't want to leave trails in the server logs or whatever reason. I right-click on the link to access "Copy Link Localtion". The link has an onclick handler (unfortunately *very* common together with window.open). onclick triggers, the window opens, the page loads. Bummer, privacy violation.

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

A while ago on one of the w3c email list archives, I was following a discussion about how to deal with the fact that the attribute "target" has been depricated for all but the frameset dtd's. What many people did if they wanted links on their page to open in a new window was to put: <a href="somepage.html" target="_blank">. The argument against the target attribute for anything other than frames was that it forced the link to open in a new window with no recourse for the user. It also provided no information about the content within the a tag. The solution that was finally agreed upon was doing something like: <a href="sompage.html" onclick="newWin(this.href); return false;"> where newWin() contains a window.open syntax The argument for this is that new windows should be scripted rather than be part of the html spec AND a user can diable the new window by by simply turning javascript off. It is also much better than the other scripting alternative: <a href="javascript:newWin(somepage.html);"> because the link is dead unless a user turns on javascript where, in the onclick example, the link is still visitable even with javascript turned off. Now to how the above relates to this bug... When I use this script, my intention is to open the link in a new window when the link is LEFT clicked (just like you would go to any normal link). However, if I don't want to follow the link, but rather just copy it or bookmark that specific link, it becomes impossible if the onclick is triggered on a RIGHT click. I use this extensively on the following page: http://www.visi.com/~hoju/humor.html Now, you can make the argument that I shouldn't do this in the first place, but who are you to judge my intentions (and vice versa). Please just accept the fact that I do it...and, btw, you may also notice the the page is HTML 4.01 STRICT and CSS compliant. I can see the argument that the onclick handler should catch any click and then we should check in javscript which button it was... and I may very well do that as a workaround, but you still have the problem with user and developer expectation where onclick (implicitly) means LEFT click. If you attempt to solve this with the whole quirks-vs-standards modes, that really doesn't get to the issue because it deals much more with layout than with javascript (let me know if my assumption is incorrect here). I'm really starting to see Blake's DOM2 support argument the more I write...but, at the same time, I know it will break a ton of scripts out there currently. In the meantime, I will be updating my script to check for which mouse button was clicked and do nothing on a RIGHT click. hmmmm...??????? Jake

> <a href="somepage.html" target="_blank">. > The argument against the target attribute for anything other than frames was > that it forced the link to open in a new window with no recourse for the user. Who said that? Do you have a reference? Because I strongly disagree, but it's not the topic of this bug.

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

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.

I think the spec. makes it pretty clear and it makes sense when you consider that the Mac has only one click button and linux supports three buttons. When you have an onclick event, you should check button attribute to see which button was clicked (0 left, 1 middle, 2 right). This is a nice, clean, generic, cross-platform solution except for the case of the occasional annoying site which wants to disable your right to right click on some aspect of their site. using event.preventDefault() for onclick with event.button == 2 would in theory cancel the contextmenu. As I said on n.p.m.dom ng, I think that ideally you need to give the user the right to keep their contextmenu, but also the author the right to let them know that they are missing out if the user chooses to disable it. repost from ng: "I would think that the user should have the following choices: 1) accept authors context menus 2) combine authors context menu with mozilla context menu 3) accept only mozilla context menus I would also think that if someone is operating in the third mode, there should be a way for the author to let them know that they are "missing out" on the feature, i.e. some way for the author to see if oncontextmenu has been disabled and encourage them to enable it for that site only." A major problem is that many things are coarse grained... in the past the only choice was to disable scripts. We need to give the user choices for the most obviously intrusive abuses (spawning new windows, disabling context menus, taking away chrome, keeping focus, etc.), but we also need to give the author the right to know how their page is being viewed, what options the user is permitting them to use, etc. If a particular web app would not be easy to implement withouth a context menu, the author has the right to tell the user that the web app is severely limited because they have disabled that feature. Without compromising user security.

Dylan, let's discuss this on the newsgroup. My reply there.

I found an example on webreview.com where what I expect upon a right click of a particular link is Mozilla's context menu. However, what happens is a new window gets popped up and I don't see any context menu. To see it in action, go here: http://www.webreview.com/style/ and click on the "Browser Compatibility Chart Key" link (near the middle of the page). here's the "offending" code: <a href="/style/key.shtml" onClick="window.open ('/style/key.shtml','key','toolbar=no,width=400,height=400,status=no,location=no ,scrollbars=yes,resize=yes,menubar=yes');return false"><b>Browser Compatibility Chart Key</b></a> Now this isn't just "spawning new window" in a bad sense; this window is supposed to be small and suppposed to be there as a reference key for other pages. Now, this example is almost exactly like what I described in my previous post. What I *should* be able to do is Left click to follow the link (or pop up a new window... whatever the author intended to happen) OR Right click and get a context menu that would allow me to do one of a number of things like; copy the link location, bookmark the link, open the link in a new window, save link as..., Edit link in composer, etc... Like I argued earlier, using the onclick to open a window rather than target="_blank" both provides conformance to the strict DTD's AND, more importantly, provides a way for the author to provide some intended functionality while respecting the user's preference about what to do with the link. Keep in mind, the other alternative, href="javascript:window.open(...)", both breaks the link for users who disable javascript and provides no recourse for the user who has javascript enabled. Plus, even with javscript enabled, the link isn't really bookmarkable! The problem is (barring a massive evangelism campaign on letting developers know that they should check which mouse button was clicked before running their code) that Mozilla will break scripts like this and, along with that, developer and user flexibility. Is there truly no solution to comply with the spec AND default OnClick to the main mouse button (usually left on Windows)??? If a solution could be created, it would keep Mozilla from being that "bastard browser that keeps breaking my scripts", but rather that "cool new browser that my existing scripts still work with". Jake

This is really a UI design issue at this stage. Do we want to go against the spec? Sending to UI Design for feedback.

> Do we want to go against the spec? blake, as I said, the HTML spec is not clear here. Common interpretation is "left click only". And the DOM2 spec does not matter, when you are rendering documents that were written before the DOM2 spec existed. So, please don't say that this behaviour were against "the spec".

This is simple from a usability standpoint. Remote content should never be able to respond to, or interfere with my use of, a secondary mouse button. Not ever. To do so would allow malicious Web authors to reduce Mozilla's usefulness, and/or to restrict users' ability to use (or link to) the author's content. The main thing this would achieve would be to force users to switch to a browser other than Mozilla, a browser which didn't allow remote content to do these things. So if the DOM spec says this, or any other spec present or future, the spec will be proven wrong by user force. Back to Event Handling.

Moving back to the 0.9.2 milestone. Tom, as we decided on the phone, lets re-examine this bug and figure out what to do here. Currently, the click handlers get fired for right clicks on anchors but not for right clicks on buttons. That seems inconsistent and should be addressed. Some ideas you mentioned during our phone conversation were a) to support backwards compatible behavior via quirks mode code b) to implement the Activate event as prescribed by the Accessibility WG

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

I strongly disagree with the statement that "Remote content should never be able to respond to, or interfere with my use of, a secondary mouse button. Not ever." Witness the case of many web applications - surveys, HR forms, stock trading, etc." which have in big bold type at the top of the page "Do not use your browser's back button for doing so will cause [multiple data submissions/lost data/general havoc]". If I'm a developer which is trying to use Mozilla as a platform to deliver application-like content, and I want to provide other semantics on the right mouse button or explicitly prevent the contextual menu from popping up, I should be able to do so. This is explicitly required for compatibility. Witness Netscape's own Javascript 1.3 spec (http://developer.netscape.com/docs/manuals/js/client/jsref/handlers.htm#1119876 ) There, the onClick event is spec'ed to take an event parameter which, among other things specifies the "which" field, which specifies the button number pressed. If onClick stops being fired for right mouse buttons, any older Javascript which takes action only on the right mouse button will now stop working. So the most "right" way to handle this case would be to allow onClick to fire for all buttons and for developers who are interested in a particular mouse button to explicitly trap that mouse button for a particular behavior. I suppose the most compatible compromise would be that for inline scripts with no arguments (of the form onClick="Do something interesting") that the default behavior should be not to fire for buttons other than the default; in practice, though, this strikes me as really, really ugly - and may not be workable in any case.

aoki, - right mouse button in general is discussed on newsgroup .dom - as shown with many examples here and as you can easily witness yourself at many sites, the current solution has serious "compatibility" problems by being triggered unintentionally (intended by neither the web developer nor the user). Netscape Navigator 4.x (at least here on Unix) doesn't show this behaviour.

> "Do not use your browser's back button for doing so will cause [multiple data > submissions/lost data/general havoc]". It is easy enough to do prevent such havoc on the server side, as Bugzilla demonstrates. > If I'm a developer which is trying to use Mozilla as a platform to deliver > application-like content Then you need to keep in mind that it's not your Web browser. It's the user's. Not yours. Theirs. You need to accept the limitations of the medium (only one mouse button, no control over context menus), in return for the advantages you have gained (cross-platform execution, no need for installation on the user's machine, etc). > and I want to provide other semantics on the right mouse button or explicitly > prevent the contextual menu from popping up Then not only would you be immensely annoying, but your app also wouldn't work in iCab, Navigator 4.x, Internet Explorer 5.0 for Mac OS, and probably other browsers which I haven't tested yet. Again, if Mozilla allows remote content to interfere with use of the right mouse button, then users will avoid it in favor of those browsers which don't.

mpt: well written. Why don't you encourage the same approach for accesskeys ;-?

(I do -- see bug 55020.)

I think the discussion should not be restricted to right click and context menus. Middle click (open in new window/paste URL) has the same problem. See bug 70135: Pretty annoying testcase: http://www.elnet.com.br/elnet_news/index.asp In the white-backgrounded middle column ("Notícias e Matérias"), every link is a popup. In IE and 4x (it wasn't me who tested, but I saw it), middle-clicking or right-clicking on any of them does what it's supposed to do, with no popup. The popup only appears in left-click. So, now I'm inclined to say "no pref, just block it!" Getting left-click only is the most useful behavior (ie parity, 4x parity, and the fact that you shouldn't have to check for the button in every onclick handler). If the DOM has a way to know which button was pressed, this does not mean that mozilla has to give a way to send presses of other buttons to scripting; it just means that _if_ it does, which button was pressed should be available in a specific way. Nobody here has said the DOM spec says "you must be able to send clicks of all buttons to scripting".

Removing "on a link" from SUMMARY again, since the bug is not limited to link, as you can easily witness on Google's ads, e.g. currently at <http://www.google.com/search?q=auto+buy>. See initial description.

Moving lower priority bugs out of .9.2 milestone.

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

Doesn't look like this is getting fixed before the freeze tomorrow night. Pushing out a milestone. Please correct if I'm mistaken.

->0.9.5

Hey, who made this topembed and why? Just making sure it really needs to be on that radar. Thanks.

It was me. One of our developers has an issue with this, as right-clicking not only will pop a context menu, but also initiate the onclick (left click) event. Jud-Will this have to be yet another embeddor setting?

I vote it should be fixed. The DOM2-Events spec talks about these events occuring when a "pointing device button" is pressed but I don't see anything that says Mozilla *must* generate events for every button. As I interpret it, we could send events for every button but then again we don't have to. The current behaviour clearly screws with the context menus so it should be changed for untrusted content. Chrome probably still needs to receive these events whatever button was clicked.

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

Bug 89296 also occurs with middle-clicking and ctrl+clicking. Should those events also not be sent to untrusted content?

See bug bug 86193 for more discussion about whether pages should be able to interfere with context menus. (Note that that's not exactly the same question as whether pages should see *onclick* for right-click events.)

this is broken behavior IMO. I suspect another manifestation of this is left click selecting a mail message, than quickly right clicking it. That process causes the messsage to be opened in a new window as though it had been double left clicked. it's a major pain.

Valeski, that's covered by bug 86468, Left/Right clicks undiscriminated for double-clicks. I don't know whether it's actually the same problem as the one in this bug.

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

raising severity per embedding customer request

Attaching patch. This patch disables right and middle mouse clicks on all content objects (with the exception of text fields due to a compatibility bug with existing code). It does not disable right and middle mouse clicks on documents, windows, and in the browser chrome. These events are already widely used within the browser to provide internal functionality. In addition, the firing of middle and right clicks is correct per the DOM 2 Event spec and required for the coding of complex applications. No equivalent event exists. It is hoped that the current patch will fix all the bug cases in question. It has been tested and does fix the simple and common cases attached to this bug.

sr=hyatt

Comment on attachment 50941 [details] [diff] [review] proposed patch looks good to me, r=saari

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

Come to PDT @ noon to get your +, if no one gives it to you tonight.

joki, I'm confused about your comment: >Attaching patch. This patch disables right and middle mouse clicks on all >content objects ... >the firing of middle and right clicks is correct per the DOM 2 Event spec and >required for the coding of complex applications. No equivalent event exists. The first part sounds like you're not sending onclicks to web page objects, and the second part sounds like you are sending onclicks to them. What am I missing?

Does the patch do anything to ctrl+left-clicks? Ctrl+clicking on a link has the same meaning to the user as middle-clicking it, so it would seem strange if web pages accidentally intercepted one but not the other. On the other hand, javascript minesweeper games need some way to know whether you're trying to mark a mine or dig in a square. At least one minesweeper game (http://www.the5k.org/description.asp/entry_id=508) tells Mozilla users to ctrl+click instead of right-clicking in order to mark mines.

Moving to nsbranch+, please attend one of today's PDT meetings. What kind of testing needs to be done to ensure this does not introduce any regressions?

check it in - PDT+. Pls update Patch Status with "has super review"

Fix checked into branch 9/27. Will go into trunk today, 9/28.

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

Moving to 0.9.6 at request of drivers@mozilla.org

Verified this on the 094 branch builds Win32 and Mac for the original test case and for Jud Valeski's case re: mail. However, for the testcase above dated 9-19, I do get the alert on the Mac, but not on Win32. I suspect this is because on the Mac, I don't have a left/right mouse button.

since this bug was checked in to 0.9.4, I'm removing topembed designation. Please make sure that the problem is also fixed on the branch (for future embedding clients). Thanks.

Um... This patch does not define a default value for mLeftClickOnly. If the pref is not set for some reason, we'll default to a randomly determined state.... We should really initialize this bool.

You're absolutely correct but that actually got noticed before the fix got checked in so the trunk version has the preset bool. I guess we never got the patch updated for the minor revision. And since this is on the trunk at this point I'm going to go ahead and close this.

So does the 0.9.4 branch properly set the default value? If not, can that be pushed?

EDT - added comment fixed0.9.4. talked to tom- the default value is properly set on the branch.

removing edt0.9.4 nomination.

This attachment shows a bug with right-click on google results pages when signed into a google account and using web history. This bug does not exist in IE or Chrome. Google appears to change the target of the link, using javascript, when the user clicks on it. However, the link is also changed when the user right-clicks on it, which is not the expected behavior. This can be reproduced by anyone when signed into a google account with web history enabled.