Last Comment Bug 71705 - Right-click triggers onclick handler
: Right-click triggers onclick handler
Status: RESOLVED FIXED
[p-ie/mac][p-icab] ETA 9/26, [PDT+] [...
:
Product: Core
Classification: Components
Component: Event Handling (show other bugs)
: Trunk
: x86 All
: P4 critical with 3 votes (vote)
: mozilla0.9.6
Assigned To: joki (gone)
: Zach Lipton [:zach]
: Andrew Overholt [:overholt]
Mentors:
http://freshmeat.net/projects/gnoise/
: 73172 81434 81610 89296 99822 101841 102149 (view as bug list)
Depends on: 28604
Blocks: 377819 64833 107066
  Show dependency treegraph
 
Reported: 2001-03-12 11:14 PST by Ben Bucksch (:BenB)
Modified: 2009-02-04 20:26 PST (History)
22 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Simple testcase. Just right-click and see how the alert is showed (140 bytes, text/html)
2001-09-19 05:26 PDT, Vicente Salvador
no flags Details
proposed patch (8.82 KB, patch)
2001-09-26 13:12 PDT, joki (gone)
saari: review+
joki: superreview+
Details | Diff | Splinter Review
screenshots of problem on google results page with right-click (226.86 KB, application/zip)
2009-02-04 20:26 PST, publicjanak
no flags Details

Description Ben Bucksch (:BenB) 2001-03-12 11:14:32 PST
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.
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2001-03-14 09:08:53 PST
Over to event handling
Comment 2 Ben Bucksch (:BenB) 2001-03-14 10:00:56 PST
I think, I saw this in 0.6 already.
Comment 3 Loco 2001-03-14 10:23:19 PST
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.
Comment 4 Loco 2001-03-14 10:32:25 PST
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.
Comment 5 Blake Ross 2001-03-14 11:41:15 PST
Right click is supposed to fire onclick. What's the issue?
Comment 6 Ben Bucksch (:BenB) 2001-03-14 13:55:23 PST
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.
Comment 7 Ben Bucksch (:BenB) 2001-03-14 14:04:14 PST
> 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.
Comment 8 Blake Ross 2001-03-14 15:51:30 PST
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.
Comment 9 sairuh (rarely reading bugmail) 2001-03-14 19:47:38 PST
methinks this bug won't get fixed for 0.8. renominating.
Comment 10 Loco 2001-03-14 20:48:27 PST
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.
Comment 11 Blake Ross 2001-03-14 20:57:04 PST
> 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?
Comment 12 joki (gone) 2001-03-16 05:02:21 PST
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.
Comment 13 Ben Bucksch (:BenB) 2001-03-16 05:44:23 PST
> 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.
Comment 14 Ben Bucksch (:BenB) 2001-03-21 06:12:21 PST
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.
Comment 15 Phil Schwartau 2001-03-23 07:46:07 PST
*** Bug 73172 has been marked as a duplicate of this bug. ***
Comment 16 Jacob Kjome 2001-03-30 10:56:46 PST
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
Comment 17 Ben Bucksch (:BenB) 2001-03-30 13:34:09 PST
> <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.
Comment 18 Jesse Ruderman 2001-04-04 12:52:13 PDT
See also bug 72084, "There is no way to disable the context menu upon right-
click".
Comment 19 Taras Tielkes 2001-04-05 14:25:09 PDT
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 20 Dylan Schiemann 2001-04-06 14:45:39 PDT
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.
Comment 21 Ben Bucksch (:BenB) 2001-04-06 15:33:13 PDT
Dylan, let's discuss this on the newsgroup. My reply there.
Comment 22 Jacob Kjome 2001-04-12 12:41:35 PDT
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
Comment 23 Blake Ross 2001-04-12 12:52:36 PDT
This is really a UI design issue at this stage.  Do we want to go against the 
spec?  Sending to UI Design for feedback.
Comment 24 Ben Bucksch (:BenB) 2001-04-12 16:36:15 PDT
> 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".
Comment 25 Matthew Paul Thomas 2001-04-13 12:30:55 PDT
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.
Comment 26 Nisheeth Ranjan 2001-05-15 16:13:32 PDT
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
Comment 27 Keyser Sose 2001-05-21 22:20:18 PDT
*** Bug 81610 has been marked as a duplicate of this bug. ***
Comment 28 Edwin Aoki 2001-05-23 12:32:14 PDT
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.
Comment 29 Ben Bucksch (:BenB) 2001-05-23 17:01:06 PDT
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.
Comment 30 Matthew Paul Thomas 2001-05-24 10:53:51 PDT
> "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.
Comment 31 timeless 2001-05-24 17:53:01 PDT
mpt: well written. Why don't you encourage the same approach for accesskeys ;-?
Comment 32 Matthew Paul Thomas 2001-05-28 09:09:36 PDT
(I do -- see bug 55020.)
Comment 33 Cesar Eduardo Barros 2001-06-15 05:03:45 PDT
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".
Comment 34 Ben Bucksch (:BenB) 2001-06-19 00:00:11 PDT
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.
Comment 35 joki (gone) 2001-06-19 11:39:38 PDT
Moving lower priority bugs out of .9.2 milestone.
Comment 36 joki (gone) 2001-06-27 14:55:24 PDT
*** Bug 81434 has been marked as a duplicate of this bug. ***
Comment 37 Blake Ross 2001-07-24 00:11:44 PDT
Doesn't look like this is getting fixed before the freeze tomorrow night.
Pushing out a milestone.  Please correct if I'm mistaken.
Comment 38 saari (gone) 2001-08-31 14:16:38 PDT
->0.9.5
Comment 39 saari (gone) 2001-09-05 11:32:53 PDT
Hey, who made this topembed and why? Just making sure it really needs to be on
that radar. Thanks.
Comment 40 Ken 2001-09-06 06:37:18 PDT
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?
Comment 41 Adam Lock 2001-09-06 07:11:05 PDT
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.
Comment 42 Olivier Cahagne 2001-09-08 10:19:52 PDT
*** Bug 89296 has been marked as a duplicate of this bug. ***
Comment 43 Jesse Ruderman 2001-09-08 21:26:37 PDT
Bug 89296 also occurs with middle-clicking and ctrl+clicking.  Should those 
events also not be sent to untrusted content?
Comment 44 Jesse Ruderman 2001-09-08 22:08:49 PDT
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.)
Comment 45 Judson Valeski 2001-09-10 09:41:40 PDT
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.
Comment 46 Jesse Ruderman 2001-09-16 00:12:55 PDT
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.
Comment 47 Boris Zbarsky [:bz] (still a bit busy) 2001-09-18 16:48:38 PDT
*** Bug 99822 has been marked as a duplicate of this bug. ***
Comment 48 Vicente Salvador 2001-09-19 05:26:12 PDT
Created attachment 49893 [details]
Simple testcase. Just right-click and see how the alert is showed
Comment 49 Marek Z. Jeziorek 2001-09-26 12:19:32 PDT
raising severity per embedding customer request
Comment 50 joki (gone) 2001-09-26 13:11:05 PDT
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 51 joki (gone) 2001-09-26 13:12:23 PDT
Created attachment 50941 [details] [diff] [review]
proposed patch
Comment 52 David Hyatt 2001-09-26 16:01:47 PDT
sr=hyatt
Comment 53 saari (gone) 2001-09-26 17:18:37 PDT
Comment on attachment 50941 [details] [diff] [review]
proposed patch

looks good to me, r=saari
Comment 54 Christopher Aillon (sabbatical, not receiving bugmail) 2001-09-26 18:06:59 PDT
*** Bug 101841 has been marked as a duplicate of this bug. ***
Comment 55 Jaime Rodriguez, Jr. 2001-09-26 22:49:31 PDT
Come to PDT @ noon to get your +, if no one gives it to you tonight.
Comment 56 Jesse Ruderman 2001-09-27 04:51:06 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?
Comment 57 Jesse Ruderman 2001-09-27 08:16:38 PDT
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.
Comment 58 selmer (gone) 2001-09-27 08:31:39 PDT
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?
Comment 59 Jaime Rodriguez, Jr. 2001-09-27 12:21:37 PDT
check it in - PDT+. 

Pls update Patch Status with "has super review"
Comment 60 joki (gone) 2001-09-28 08:28:43 PDT
Fix checked into branch 9/27.  Will go into trunk today, 9/28.
Comment 61 Alfonso Martinez 2001-09-28 11:26:58 PDT
*** Bug 102149 has been marked as a duplicate of this bug. ***
Comment 62 joki (gone) 2001-10-08 09:20:52 PDT
Moving to 0.9.6 at request of drivers@mozilla.org
Comment 63 lchiang 2001-10-15 19:25:29 PDT
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.
Comment 64 Marek Z. Jeziorek 2001-10-22 18:17:27 PDT
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.
Comment 65 Boris Zbarsky [:bz] (still a bit busy) 2001-11-07 06:24:32 PST
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.
Comment 66 joki (gone) 2001-11-20 13:04:41 PST
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.
Comment 67 Ken 2001-11-28 21:13:55 PST
So does the 0.9.4 branch properly set the default value? If not, can that be 
pushed?
Comment 68 Marcia Knous [:marcia - use ni] 2001-11-29 15:42:05 PST
EDT - added comment fixed0.9.4. talked to tom- the default value is properly
set on the branch. 
Comment 69 Judson Valeski 2001-12-03 12:09:34 PST
removing edt0.9.4 nomination.
Comment 70 publicjanak 2009-02-04 20:26:52 PST
Created attachment 360650 [details]
screenshots of problem on google results page with right-click

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.

Note You need to log in before you can comment on or make changes to this bug.