180078 - Right click and middle click should not trigger onclick handlers

Status: RESOLVED FIXED

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

Description

[José Jeria]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021112
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021112

In our company we sometimes use the webbased Outlook to view our mail. The
problem is that when recieve a .exe file there is no way to save it. 
The reason for this is that when you left click on it, you get an alert telling
you to righ-click and choose "save as". 
But because Mozilla triggers the link when right-clicking, its impossible to
save the file. You always get the alert. 

This causes us not to be able to use Mozilla.

Reproducible: Always

Steps to Reproduce:
See Details for issue.
Actual Results:  
Mozilla triggers the link when right-clicking.

Expected Results:  
Mozilla should not trigger the link and show the contextmenu.

Comment 1

[José Jeria]

Attachment: Testcase

This is just a link with onClick="alert('...');". Lets say this links to an
file you want to download. Its impossible to download it.

The behavior now in Mozilla its pretty weird. Right-click, you get the alert.
When you dismiss it you get the contextmenu.

Comment 2

[Bart Mortelmans]

onClick is also fired when you middle-click (for opening in a new tab)... I'd
expect it not to be invoked unless you left-click... I'm rather sure this wasn't
in the builds late October.

Comment 3

[Sebastian Biallas]

As a temporary work-around you can disable popups, which will also block the
alert box (this is another (known) bug)

Comment 4

[José Jeria]

Sebastian, the bug you mention, about blocking alerts, it has been fixed...

Comment 5

[Boris Zbarsky [:bzbarsky]]

On Linux, right-click is not triggering the onclick, but middle-click is. 
Neither triggers it in build 2002-11-07-21, but 2002-11-08-21 shows the
symptoms.  This coincides exactly with the event rewrite....

Comment 6

[Bart Mortelmans]

Maybe the summary should read "Right click and middle click should not trigger
onClick".

And while we're at it: I think that Ctrl-click also shouldn't trigger onClick.
Certainly not when you selected to open a new tab with onClick. Can this be in
this bug or should I open an other one for this?

Comment 7

[Boris Zbarsky [:bzbarsky]]

separate bug.  This bug is about a regression; ctrl-click is a feature request.

Comment 8

[Rob Stow]

1.)  A site I frequently visit where this has become a problem:
http://www.newsnow.co.uk/cgi/NewsNow/NewsNow.htm?Theme=Processors
Right-clicking or Ctrl-Click on one of the news "headlines" triggers the onClick
event and causes the article to open in a new window.  With any Moz build before
Nov 14 I can use the right click or Ctrl-Click to open the link in a new tab.

I am not sure whether it is appropriate for me to put the URL above into the URL
field for this Multizilla bug.

2.) Re: comment #7
   Ctrl-click is *not* a feature request.  
   It was implemented a "long" time ago for opening a link in a new tab.


3.) I suggest we change the summary of this bug to something like 
"Only left click should trigger onClick event".   The description of the bug
should be amended to specify that "left click" does *not* include things like
Ctrl-Click, Shift-Click, etc.

4.) Re Comment #4:  for the URL I cited, disabling popups does not help.  I
*want* the link to open - just in a tab where it belongs.

5.)  Just a note for all of you Multizilla users:  I have tested the URL I cited
both with and without Multizilla 1.1.32y installed - and despite that fact that
my Multizilla prefs indicate that "target=_blank" should be forced into new tabs
 I am still getting new windows when the onClick is erroneously triggered.  I
have mentioned this in the Multizilla newsgroup.

Comment 9

[Jesse Ruderman]

> I think that Ctrl-click also shouldn't trigger onClick.

Bug 151142, enh, "modifier+click on a link (ctrl, shift) should not generate
onclick event".

Comment 10

[Brian Ryner (not reading)]

Attachment: possible fix

This patch adds NS_EVENT_FLAG_NO_CONTENT_DISPATCH to NS_EVENT_CAPTURE_MASK. 
What had been happening is that the NO_CONTENT_DISPATCH flag got cleared out
from aEvent->flags when the event was dispatched to the GlobalWindow.  Prior to
the fix for bug 124990, only NS_EVENT_FLAG_CAPTURE was passed to HandleDOMEvent
in the capturing phase, so in that case the NO_CONTENT_DISPATCH flag was not
cleared in GlobalWindowImpl::HandleDOMEvent().

I'm not 100% sure this is the best fix though; I'm still trying to figure out
the nuances of aFlags vs. aEvent->flags.

Comment 11

[Boris Zbarsky [:bzbarsky]]

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

Comment 12

[Brian Ryner (not reading)]

Comment on attachment 107646 [details] [diff] [review]
possible fix

verbal r=saari

Comment 13

[Sébastien Delahaye]

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

Comment 14

[Sébastien Delahaye]

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

Comment 15

[Johnny Stenback (:jst)]

Comment on attachment 107646 [details] [diff] [review]
possible fix

sr=jst if you make the same change for NS_EVENT_BUBBLE_MASK.

Comment 16

[Sander]

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

Comment 17

[Max Alekseyev]

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

Comment 18

[Andrew Hagen]

Nominating for 1.3b.

Comment 19

[u60234]

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

Comment 20

[Jason Bassford]

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

Comment 21

[Brian Ryner (not reading)]

checked in.

Comment 22

[Boris Zbarsky [:bzbarsky]]

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