Bug 17626 - mousemove event is really cancelable?
mousemove event is really cancelable?
Status: RESOLVED WORKSFORME
Product: WebAppsWG
Classification: Unclassified
Component: DOM3 Events
unspecified
All All
: P2 normal
: ---
Assigned To: Travis Leithead [MSFT]
public-webapps-bugzilla
: needsReview
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-28 09:56 UTC by Masayuki Nakano
Modified: 2012-09-13 01:22 UTC (History)
6 users (show)

See Also:


Attachments
testcase for the default action if preventDefault() is called (2.80 KB, text/html)
2012-06-28 16:11 UTC, Masayuki Nakano
Details
testcase for checking defaultPrevented attribute value of mousemove event (495 bytes, text/html)
2012-06-28 16:14 UTC, Masayuki Nakano
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Masayuki Nakano 2012-06-28 09:56:40 UTC
I'd like to confirm that is intentional change or a bug of the draft.

In DOM2, mousemove event isn't cancelable, but the D3E spec draft defines it's cancelable.

If that is intentional change, we will change the behavior on Gecko.
https://bugzilla.mozilla.org/show_bug.cgi?id=704423

See https://bugzilla.mozilla.org/show_bug.cgi?id=704423#c1 for the compatibility with browsers.

I think that it should be cancelable. See http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0253.html for the reason.
Comment 1 Ojan Vafai 2012-06-28 15:29:30 UTC
In the mozilla bug, you listed that Opera and IE9 allow you to cancel this event, but still update hover-state. What effect does canceling the events have that is user/developer visible?
Comment 2 Masayuki Nakano 2012-06-28 16:04:36 UTC
(In reply to comment #1)
> In the mozilla bug, you listed that Opera and IE9 allow you to cancel this
> event, but still update hover-state. What effect does canceling the events have
> that is user/developer visible?

I tested by the defaultPrevented attribute.

Additionally, IE9 doesn't change selected item by mousemove event after mousedown in listbox styled <select> element if mousemove element is consumed.
Comment 3 Masayuki Nakano 2012-06-28 16:11:35 UTC
Created attachment 1147 [details]
testcase for the default action if preventDefault() is called
Comment 4 Masayuki Nakano 2012-06-28 16:14:08 UTC
Created attachment 1148 [details]
testcase for checking defaultPrevented attribute value of mousemove event
Comment 5 Ojan Vafai 2012-06-28 17:30:08 UTC
I don't see a point in making it cancellable if cancelling it doesn't do anything. Maybe someone from IE/Opera could comment on whether it accomplishes anything else.
Comment 6 Travis Leithead [MSFT] 2012-07-13 21:53:26 UTC
Historically the spec had mousemove as not cancelable, but sometime between 2002 (http://www.w3.org/TR/2002/WD-DOM-Level-3-Events-20020712/) and 2003 (http://www.w3.org/TR/2003/WD-DOM-Level-3-Events-20030221/events.html#Events-EventTypes-complete) this was switched to cancelable and has apparently been that way ever since.

The term "mousemove" doesn't come up anywhere in the www-dom archives during that period either. So, the trail has gone cold trying to understand why the spec changed back then.

In checking IE's behavior, we explicitly ignore the canceled state for hover, as has been observed. It does not appear to have other impact that we could readily see, though we didn't follow all code paths.

I see the point of making every event that can be cancelable have some rational behavior when it is canceled, but then again, the spec already points out that this logic may not always hold true:
file:///D:/DOM3Events/D3E/html/DOM3-Events.html#event-flow-default-cancel

At this point, I'd rather not tweak the value in the spec unless there's a more substantive reason to change it.
Comment 7 Masayuki Nakano 2012-09-12 04:15:37 UTC
Excuse me, I don't understand what "WONTFIX" means for this bug.

So, starting D3E, should the mousemove event be cancelable? I mean, should defaultPrevented be able to become true if preventDefault() is called?
Comment 8 Glenn Maynard 2012-09-12 15:21:31 UTC
Note that an event being cancellable is mostly legacy; I'm not aware of any real purpose to this flag today.  It dates from when the "default behavior" of an event was thought of as a part of event dispatch, but with a couple isolated exceptions (onclick) that's no longer the case; the whole concept of default behavior is a misnomer.  It's saner to err towards cancellable, for simplicity, to always make newly-minted events cancellable, and to only maintain existing events as not cancellable for compatibility.
Comment 9 Travis Leithead [MSFT] 2012-09-12 18:00:36 UTC
(In reply to comment #0)
> I'd like to confirm that is intentional change or a bug of the draft.
> 
> In DOM2, mousemove event isn't cancelable, but the D3E spec draft defines it's
> cancelable.
> 
> If that is intentional change, we will change the behavior on Gecko.
> https://bugzilla.mozilla.org/show_bug.cgi?id=704423
> 
> See https://bugzilla.mozilla.org/show_bug.cgi?id=704423#c1 for the
> compatibility with browsers.
> 
> I think that it should be cancelable. See
> http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0253.html for the
> reason.

(In reply to comment #7)
> Excuse me, I don't understand what "WONTFIX" means for this bug.
> 
> So, starting D3E, should the mousemove event be cancelable? I mean, should
> defaultPrevented be able to become true if preventDefault() is called?

To be clear--yes, mousemove should be cancelable and defaultPrevented should become true when preventDefault() is called on this event.

There is no other tangible side-effect to cancelling this event that implementers must support.
Comment 10 Masayuki Nakano 2012-09-13 01:22:51 UTC
(In reply to comment #9)
> To be clear--yes, mousemove should be cancelable and defaultPrevented should
> become true when preventDefault() is called on this event.
> 
> There is no other tangible side-effect to cancelling this event that
> implementers must support.

Thanks, it's very clear for me!