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.
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.
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.
As a temporary work-around you can disable popups, which will also block the alert box (this is another (known) bug)
Sebastian, the bug you mention, about blocking alerts, it has been fixed...
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....
Assignee: joki → bryner
Severity: normal → major
OS: Windows XP → All
Hardware: PC → All
Summary: Right click should not trigger links → Right click and middle click should not trigger links
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?
separate bug. This bug is about a regression; ctrl-click is a feature request.
Summary: Right click and middle click should not trigger links → Right click and middle click should not trigger onclick handlers
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.
> 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".
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.
*** Bug 182918 has been marked as a duplicate of this bug. ***
Comment on attachment 107646 [details] [diff] [review] possible fix verbal r=saari
*** Bug 184688 has been marked as a duplicate of this bug. ***
*** Bug 184779 has been marked as a duplicate of this bug. ***
Comment on attachment 107646 [details] [diff] [review] possible fix sr=jst if you make the same change for NS_EVENT_BUBBLE_MASK.
Attachment #107646 - Flags: superreview?(jst) → superreview+
*** Bug 185660 has been marked as a duplicate of this bug. ***
*** Bug 186355 has been marked as a duplicate of this bug. ***
Nominating for 1.3b.
*** Bug 187690 has been marked as a duplicate of this bug. ***
*** Bug 188061 has been marked as a duplicate of this bug. ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
*** Bug 191487 has been marked as a duplicate of this bug. ***
Component: Event Handling → User events and focus handling
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.