140 bytes, text/html
8.82 KB, patch
|Details | Diff | Splinter Review|
226.86 KB, application/zip
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
Assignee: karnaze → joki
Component: Layout → Event Handling
QA Contact: petersen → gerardok
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.
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.
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 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.
19 years ago
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.
This is really a UI design issue at this stage. Do we want to go against the spec? Sending to UI Design for feedback.
Assignee: joki → mpt
Component: Event Handling → User Interface Design
QA Contact: gerardok → zach
> 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.
Assignee: mpt → joki
Component: User Interface Design → 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. ***
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".
Summary: Right-click triggers onclick handler → Right-click on a link triggers onclick handler
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.
Summary: Right-click on a link triggers onclick handler → Right-click triggers onclick handler
Moving lower priority bugs out of .9.2 milestone.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
*** 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.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.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. ***
Whiteboard: [p-ie/mac][p-icab] → [p-ie/mac][p-icab] ETA 9/26
raising severity per embedding customer request
Severity: major → critical
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.
Comment on attachment 50941 [details] [diff] [review] proposed patch looks good to me, r=saari
Attachment #50941 - Flags: review+
*** 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.
Whiteboard: [p-ie/mac][p-icab] ETA 9/26 → [p-ie/mac][p-icab] ETA 9/26, [PDT]
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?
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"
Whiteboard: [p-ie/mac][p-icab] ETA 9/26, [PDT] → [p-ie/mac][p-icab] ETA 9/26, [PDT+]
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 firstname.lastname@example.org
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Whiteboard: [p-ie/mac][p-icab] ETA 9/26, [PDT+] → [p-ie/mac][p-icab] ETA 9/26, [PDT+] [Fix checked into branch 9/27]
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.
Whiteboard: [p-ie/mac][p-icab] ETA 9/26, [PDT+] [Fix checked into branch 9/27] → [p-ie/mac][p-icab] ETA 9/26, [PDT+] [Verified fix on branch from 9/27]
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.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
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.
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.