FWIW, Blink is planning on moving to not firing click events for middle mouse clicks and already doesn't fire them for right clicks. As best I can tell, this matches Gecko and IE as well.
On Tue, Oct 22, 2013 at 6:09 PM, Travis Leithead <[hidden email]> wrote:
|
Hmm, that doesn’t seem to agree with the bug report. Can you provide test cases & results? From: [hidden email] [mailto:[hidden email]]
On Behalf Of Ojan Vafai FWIW, Blink is planning on moving to not firing click events for middle mouse clicks and already doesn't fire them for right clicks. As best I can tell, this matches Gecko and IE as well. On Tue, Oct 22, 2013 at 6:09 PM, Travis Leithead <[hidden email]> wrote:
|
In reply to this post by Ojan Vafai-2
On 10/23/13 2:30 PM, Ojan Vafai wrote:
> FWIW, Blink is planning on moving to not firing click events for middle > mouse clicks and already doesn't fire them for right clicks. As best I > can tell, this matches Gecko and IE as well. It certainly doesn't match Gecko. Note that Gecko will fire non-left clicks directly on the document, so depending on how you wrote your testcase you may have not seen the events. -Boris |
+Daniel who did the testing. Daniel, can you share your test case and the results?
On Wed, Oct 23, 2013 at 1:31 PM, Boris Zbarsky <[hidden email]> wrote:
That's right. I had forgotten about this. I'd only want to do this if we were required to by web-compat.
|
The bug where we're tracking this is:
(I just added some Q&D test cases to the bug) On Wed, Oct 23, 2013 at 1:34 PM, Ojan Vafai <[hidden email]> wrote:
|
In reply to this post by Ojan Vafai-2
On Wed, 23 Oct 2013 22:34:52 +0200, Ojan Vafai <[hidden email]> wrote:
> +Daniel who did the testing. Daniel, can you share your test case and > the results? > > On Wed, Oct 23, 2013 at 1:31 PM, Boris Zbarsky <[hidden email]> wrote: > > >> On 10/23/13 2:30 PM, Ojan Vafai wrote: >> >>> >>> FWIW, Blink is planning on moving to not firing click events for middle >>> >>> mouse clicks and already doesn't fire them for right clicks. As best I >>> >>> can tell, this matches Gecko and IE as well. >>> >> >> >> >> It certainly doesn't match Gecko. >> >> >> >> Note that Gecko will fire non-left clicks directly on the document, so >> depending on how you wrote >>your testcase you may have not seen the >> events. > > That's right. I had forgotten about this. I'd only want to do this if we > were required to by web->compat. The data is at: http://i.imgur.com/039VHDk.png (sorry for the poor format, it was the least complicated way of getting a document published at the time) Gecko does indeed fire a click event in most cases when the user presses and releases the middle button of the mouse, but according to the documentation in the Bugzilla bug, that was just to keep some internal functionality working. It is not a standard event since its target is the node you interact with, but it's not dispatched there but at the document (where it's unlikely to be seen). The root problem is, how to make sure this click handler doesn't run when people use the middle button: <a href="page.html" onclick="foo()">Middle click this link</a> All browsers address that in different ways, but the absolutely simplest and cleanest solution is to not dispatch the event at all. It does mean that some browsers may have to rethink how they implement some UI functionality (in case that internally is hooked into the "click" event), and I'm looking at such a case in Chromium/Blink but that doesn't change my opinion that the world will be a better place if web pages never see any click event at all except for when the user uses the main mouse button. /Daniel |
On Thu, Oct 24, 2013 at 2:27 AM, Daniel Bratell <[hidden email]> wrote: Gecko does indeed fire a click event in most cases when the user presses and releases the middle button of the mouse, but according to the documentation in the Bugzilla bug, that was just to keep some internal functionality working. It is not a standard event since its target is the node you interact with, but it's not dispatched there but at the document (where it's unlikely to be seen). It doesn't seem all that unlikely, since you'll see it if you're using event delegation with your listener on the document or the window. That's probably not common (typically event delegation is done on a container for a set of specific elements, and not the entire document), but it doesn't seem too far out there.
(I'm naively curious why they didn't fire a different "click" event name for their internal stuff that needed it on middle click, instead of introducing yet another bizarre glitch onto the Web.) -- Glenn Maynard |
On 10/24/13 10:12 AM, Glenn Maynard wrote:
> (I'm naively curious why they didn't fire a different "click" event name > for their internal stuff that needed it on middle click, instead of > introducing yet another bizarre glitch onto the Web.) I think you have it backwards. The DOM spec back when this was implemented in Gecko required firing clicks for all mouse clicks (and in fact the click event said which button got clicked). When Gecko implemented the spec as written, this was discovered to be not compatible with web sites. Note that the spec was somewhat abandonware at that point, in that the working group that had written it no longer existed. So given that, Gecko implemented as minimal a spec violation as possible that was still compatible with sites. Maybe we should have gone for a bigger spec violation, but please don't make it out like this was driven solely by "internal stuff". -Boris |
On Fri, Oct 25, 2013 at 12:09 AM, Boris Zbarsky <[hidden email]> wrote: -- When Gecko implemented the spec as written, this was discovered to be not compatible with web sites. Note that the spec was somewhat abandonware at that point, in that the working group that had written it no longer existed. Firing an event on one element with .target set to a different element depending on which button is pressed was viewed as a lesser violation than just not firing the event for those buttons? That's a bit nuts. Anyway, hopefully it's possible to remove it. Maybe we should have gone for a bigger spec violation, but please don't make it out like this was driven solely by "internal stuff". I'm not making anything out to be anything, I'm replying to somebody who said "according to the
documentation in the Bugzilla bug, that was just to keep some internal
functionality working". Maybe he misread the history, but you're talking to the wrong person. Glenn Maynard |
Free forum by Nabble | Edit this page |