319347 - A "click" event should only occur if the mousedown and mouseup were in the same location

Status: VERIFIED INVALID

(Core :: SVG, defect)

Description

[Timmy Brolin]

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."

Reproducible: Always

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.

Actual Results:  
When you release the mouse button after dragging the SVG image, a click event is also issued, causing the SVG image to zoom in.

Expected Results:  
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.

Comment 1

[Anne (:annevk)]

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>).

Comment 2

[Timmy Brolin]

Attachment: 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..

Comment 3

[Timmy Brolin]

(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.

Comment 4

[Anne (:annevk)]

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.)

Comment 5

[Timmy Brolin]

(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
> large.)

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?

Comment 6

[Timmy Brolin]

http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-mouseevents-h3
"
click
    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.

Comment 7

[Jonathan Watt [:jwatt]]

Attachment: testcase

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.

Comment 8

[Anne (:annevk)]

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.

Comment 9

[Duan Yao]

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.

Comment 10

[Robert Longson [:longsonr]]

The specification says: https://w3c.github.io/uievents/#events-mouseevent-event-order

Each implementation will determine the appropriate hysteresis tolerance, but in general SHOULD fire click and dblclick events when the event target of the associated mousedown and mouseup events is the same element with no mouseout or mouseleave events intervening, and SHOULD fire click and dblclick events on the nearest common inclusive ancestor when the associated mousedown and mouseup event targets are different.

So the mouse doesn't have to be in the same location.

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Yes, it is. click event is designed and implemented for that usual web apps can take similar behavior as button widgets on native applications. E.g., dragging out from a button does not cancel to click it immediately. I.e., users can click it even after that if they move cursor into it and release the mouse button over it.

Therefore, web apps like mentioned in comment 9 need to handle mouse, touch and/or pointer events by themselves since they want custom behavior about considering the click/tab on same position. So if developers think that an event behavior does not make users happy on the their apps, I think that they should investigate it more whether the custom behavior won't make their users confused or will make them happier (in my experience, developers should be conservative against changing basic UI behavior for avoiding users confused) and whether the DOM tree structure is logically reasonable or not (e.g., using an element for different purpose from the intention when it's standardized may cause the other things complicated).

Anyway, current click event behavior is compatible between browsers, click event is a logical event (i.e., not device's physical event) and the behavior enough emulates native applications' behavior on each major OS. So we shouldn't change the behavior.