User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
This affects SVG scripting.
Every time the mouse button is released a new Click event is issued, even when the mouse has moved since the mousedown event.
The SVG specification says: "A click is defined as a mousedown and mouseup over the same screen location."
Steps to Reproduce:
See the link for a simple example.
Click the SVG image to zoom in. Press your Shift key and click to zoom out. This works as it should.
Now, try dragging the SVG image.
When you release the mouse button after dragging the SVG image, a click event is also issued, causing the SVG image to zoom in.
No click event should be issued when releasing the mouse button after dragging the image. (The SVG image should not zoom in when releasing the button after after dragging)
This works as it should using the Adobe plugin for IE.
The target node does not change while dragging so per DOM3Events I guess this is INVALID (<http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-click>).
Created attachment 205171 [details]
Same test, with no drag feature
No, it should not cause a click. The attached file is the same test, but with the drag feature removed.
Try the same thing with this file. Press mouse button, drag, and release. It will still cause a Click event when it should not.
Oh, and don't put the cursor on top of the text when trying this. Mouse events over text are sometimes missed..
(In reply to comment #1)
> The target node does not change while dragging so per DOM3Events I guess this
> is INVALID (<http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-click>).
I think your interpretation of the text you are linking to is flawed.
Target node not changing between mousedown and mouseup is not the definition of a click. The text states that "The definition of a click depends on the environment configuration; i.e. may depend on the screen location or the delay between the press and release of the pointing device button."
Target node not changing between mousedown and mouseup is just a fact which must be true no matter which definition of "click" is used.
A problem with that testcase is that it catches the event on the svg:g element which is probably as large as the screen. (I'm not entirely sure about that, but its parent element, svg:svg is, and one of its descendents is also very large.)
(In reply to comment #4)
> A problem with that testcase is that it catches the event on the svg:g element
> which is probably as large as the screen. (I'm not entirely sure about that,
> but its parent element, svg:svg is, and one of its descendents is also very
I assume you are talking about the second test I posted as an attachement.
Yes, the svg:g element is larger than the screen.
Why would that be a problem?
The click event occurs when the pointing device button is clicked over an
element. A click is defined as a mousedown and mouseup over the same screen
location. The sequence of these events is:
I think the specification is quite clear on the definition of a Click.
If the mouse has moved between mousedown and mouseup, then the two events did not occur over the same screen location, and there should be no Click event. Mozilla obviously does not take mouse movement into acount when issuing Click events.
Created attachment 290268 [details]
This testcase makes things a bit easier to see. If you mousedown and mouseup on the same square, you'll get a click event. If you mousedown one one square and then mouseup on the other (or neither) square, you will not get a click event.
Behavior in that testcase seems like how this should work. DOM specification should be fixed to be way more specific about hit testing and targets in line with how this is implemented.
It seems most modern desktop browsers (Firefox, Chrome, Edge, if not all) do the same thing now: fire a click event no matter how far the mouse has moved and how long time has elapsed between mousedown and mouseup, as long as the mouse keeps in the same element.
However, I think this is an unfortunate behavior, because it makes it very difficult to build an app that support both dragging and click in a same scene.
In one of my project, I have to implement a custom 'tap' event which only fires if mousedown and mouseup are in (almost) the same location and happens within 500ms. When it comes to <a>, I have to cancel the default click event and fire an synthesized click event by calling .click() on 'tap'. It is a mess.
Additionally, mouse click is diverged from touch click: browsers don't fire a click event if the touch has moved or a long time has elapsed between touchstart and touchend. I think the latter is exactly what most users would expect, and mouse click should be fixed in both browsers and in the spec. Note that pointer event API is coming, I think it will be unfortunate if developers still have to struggle with different types of 'click' with this unified API.