Last Comment Bug 319347 - A "click" event should only occur if the mousedown and mouseup were in the same location
: A "click" event should only occur if the mousedown and mouseup were in the sa...
Status: UNCONFIRMED
:
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: x86 Windows 2000
-- normal with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jet Villegas (:jet)
Mentors:
http://www.brolinembedded.se/misc/cli...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-06 13:32 PST by Timmy Brolin
Modified: 2016-01-15 04:13 PST (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Same test, with no drag feature (851 bytes, image/svg+xml)
2005-12-06 14:27 PST, Timmy Brolin
no flags Details
testcase (193 bytes, image/svg+xml)
2007-11-26 13:14 PST, Jonathan Watt [:jwatt]
no flags Details

Description User image Timmy Brolin 2005-12-06 13:32:19 PST
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 User image Anne (:annevk) 2005-12-06 13:55:28 PST
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 User image Timmy Brolin 2005-12-06 14:27:20 PST
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..
Comment 3 User image Timmy Brolin 2005-12-06 15:48:44 PST
(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 User image Anne (:annevk) 2005-12-07 01:42:54 PST
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 User image Timmy Brolin 2005-12-07 03:23:35 PST
(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 User image Timmy Brolin 2006-10-28 03:53:38 PDT
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 User image Jonathan Watt [:jwatt] 2007-11-26 13:14:12 PST
Created attachment 290268 [details]
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 User image Anne (:annevk) 2013-09-12 11:30:59 PDT
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 User image Duan Yao 2016-01-15 04:13:01 PST
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.

Note You need to log in before you can comment on or make changes to this bug.