User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0 Build ID: 20160220030407 Steps to reproduce: ok, there was https://bugzilla.mozilla.org/show_bug.cgi?id=1249924 and it's invalid because of specs. now see https://jsfiddle.net/2uyetfws/ I want to prevent openning of link in new tab when middle button clicking occurs. Actual results: new tab openning is not prevented Expected results: new tab openning should be prevented

You'd have to code it as something that isn't a real link or put something invisible over the top of it that intercepts the mouse clicks. This is something for you to do rather than a Firefox bug.

This may give you some more ideas: http://stackoverflow.com/questions/17169198/how-to-disable-or-hide-the-open-in-new-tab-option-for-hyperlinks

Robert so you offer some workaround and talk it's allright that we can prevent link openning on left mouse clicks but can't prevent it for any other button. I don't get why it's not bug.

and, btw, link is a link. I don't need to hide options in context menu for it and moreover I'd need to add options (all that 'copy link location' etc) if I'm going to mask some other element as link.

right clicks lead to the browser's UI, you can't disable it (web pages can't take over) but you can modify it a little and add items e.g http://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_global_contextmenu

that's cool but I actually don't want to modify right clicks behaviour anyhow. the issue is about never-gonna-stop-me middle button.

Well this is a bug reporting site and there's no spec bug here. If you want to know how to do something and you're stuck stackoverflow is pretty good at answering such questions.

well what I see in the specs: 1. https://www.w3.org/TR/uievents/#h-event-flow-activation "Certain event targets (such as a link or button element) MAY have associated activation behavior (such a following a link) that implementations perform in response to an activation trigger (such as clicking a link)." 2. https://www.w3.org/TR/uievents/#h-click-synthesis "Preventing the default action of the activation trigger, such as with the Event.preventDefault(), MUST stop the initiation of the activation behavior." I have a link (https://www.w3.org/TR/html5/links.html#hyperlink) with invoked activation behavior (https://www.w3.org/TR/html5/links.html#following-hyperlinks-0) which I can't stop. so I call it a bug and ask you why do you not. P.S. sorry if I sound stupid, it's not my native language. and, thanks, I know about existing of Stack Overflow.

2 is about click. As your other bugs have told you when the spec says click it means left click. Right clicks are contextmenu activation events. You'd need to have a handler for contextmenu events.

Although since you're talking about middle clicks, this might help http://stackoverflow.com/questions/1795734/triggering-onclick-event-using-middle-click

yes, I see what specs say: click event only for left button. and I've even added comment about it on JSFiddle example. this issue NOT about click as 'click' event, that's why I've opened it. again, I have invoked activation behavior for hyperlink and I can't stop this behavior. specs say it may be stopped and must be stopped if Event.preventDefault() is called. part of the problem is that I don't know what is it's activation trigger (I can't figure out it since debated activation behavior is non-stopping in Firefox). surely it isn't 'click' event since 'click' event can't be fired by middle button.

when I click on link by middle button two events occur on it: 'mousedown' and 'mouseup'. most likely it's should be 'mouseup' event as activation trigger resulting in https://www.w3.org/TR/html5/links.html#following-hyperlinks-0 in new tab as activation behavior.

I *think* https://bugzilla.mozilla.org/show_bug.cgi?id=1249922#c2 applies here, too, but I'll defer to smaug.

Andrew https://bugzilla.mozilla.org/show_bug.cgi?id=1249970#c11

(In reply to Andrew Overholt [:overholt] from comment #13) > I *think* https://bugzilla.mozilla.org/show_bug.cgi?id=1249922#c2 applies > here, too, but I'll defer to smaug. oh, a bit different. We shouldn't fire click even for chrome since mouseup has been cancelled.

er, wait, preventDefault() doesn't cancel click.

So from DOM point of view this is not a bug. If you want FF UI to behave differently, file a bug on it, since that is where middle click is being handled. (it could perhaps check the defaultPrevented status of mouseup events)

> If you want FF UI to behave differently yep, that's what I want. sorry, I'm far from understanding of FF's internal mechanics and can't explain it in a few words correctly. > file a bug on it https://bugzilla.mozilla.org/show_bug.cgi?id=1250652