Created attachment 142243 [details] test case * Mousedown/up without moving the cursor on the purple rectangle. * Expected: print 'clicked' ✔ Observed: print 'clicked' * Mousedown on the rectangle and move the mouse around the purple rectangle. * Mouseup with the mouse still on the rectangle. * Expected: NO message ✘ Observed: a message is printed According to http://www.w3.org/TR/SVG/interact.html#ClickEvent, "a click is defined as a mousedown and mouseup over the same screen location". However, a click event is fired even if the mouse is moved around the shape. I've tested IE 9 and FF 10.0.2 work as expected (no click message displayed).
This spec requirement doesn't appear practical. For usability and accessibility reasons, one cannot require that mouse position doesn't change at all during click, or it would be too difficult for some people to click. This is doubly important for double clicks, which are served by the same event (with the detail attribute incrementing with each repetition). That said, click hysteresis is not the observable difference with spec here - you can move the mouse all over the shape, not just by 2-3 pixels. I don't know if that's intentional for SVG, although it matches behavior of most built-in HTML controls.
Oh, I think this is similar to how mousedown and mouseup must happen on the same element in html although I think that's also wrong. User can't tell and shouldn't be forced to be aware of element boundary.
(In reply to comment #1) > This spec requirement doesn't appear practical. For usability and accessibility reasons, one cannot require that mouse position doesn't change at all during click, or it would be too difficult for some people to click. This is doubly important for double clicks, which are served by the same event (with the detail attribute incrementing with each repetition). > > That said, click hysteresis is not the observable difference with spec here - you can move the mouse all over the shape, not just by 2-3 pixels. I don't know if that's intentional for SVG, although it matches behavior of most built-in HTML controls. Alexey, Yes - I think the requirement of "over the same screen location" is almost always implemented actually within a bounding box of a couple pixels. The behaviour in WebKit right now is inconsistent with other HTML elements. For example, adding the same code above to a div would produce the expected results.
(In reply to comment #2) > Oh, I think this is similar to how mousedown and mouseup must happen on the same element in html although I think that's also wrong. User can't tell and shouldn't be forced to be aware of element boundary. Ryosuke, Perhaps I've misunderstood. The problem is the triggering of the "click" event and *not* the mouseup/down combo (they work as expected!). On Windows, from every implementation of click events that I've seen (.NET, Java and FF/IE), a click only occurs when the mouse goes outside of the bounds defined in SM_CYDRAG and SM_CXDRAG retrieved with GetSystemMetrics (http://msdn.microsoft.com/en-us/library/windows/desktop/ms724385(v=vs.85).aspx).
(In reply to comment #4) > (In reply to comment #2) > > Oh, I think this is similar to how mousedown and mouseup must happen on the same element in html although I think that's also wrong. User can't tell and shouldn't be forced to be aware of element boundary. > > Perhaps I've misunderstood. The problem is the triggering of the "click" event and *not* the mouseup/down combo (they work as expected!). Yes. What I meant to say is that musedown and mouseup must happen on the same element in order for click to fire. > On Windows, from every implementation of click events that I've seen (.NET, Java and FF/IE), a click only occurs when the mouse goes outside of the bounds defined in SM_CYDRAG and SM_CXDRAG retrieved with GetSystemMetrics (http://msdn.microsoft.com/en-us/library/windows/desktop/ms724385(v=vs.85).aspx). You mean when the mouse stays within the bounds? I'm certainly aware of that but that's not what the specification says.
> > On Windows, from every implementation of click events that I've seen (.NET, Java and FF/IE), a click only occurs when the mouse goes outside of the bounds defined in SM_CYDRAG and SM_CXDRAG retrieved with GetSystemMetrics (http://msdn.microsoft.com/en-us/library/windows/desktop/ms724385(v=vs.85).aspx). > > You mean when the mouse stays within the bounds? I'm certainly aware of that but that's not what the specification says. Yes, however these bounds are a tiny box (4px) and *not* the bounds of the actual shape (which is what is happening in for this bug report). Clicking is practically impossible if the mouseup/mousedown points have to be equivalent. Every browser that I've tested with uses Window's SM_CYDRAG/SM_CXDRAG for regular HTML elements to detect between a drag and a click. However, my issue is that the "click" bounds for SVG elements seem to be *the whole element* and therefore a click is always fired.