This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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 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?
(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.
Created attachment 1147 [details] testcase for the default action if preventDefault() is called
Created attachment 1148 [details] testcase for checking defaultPrevented attribute value of mousemove event
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.
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.
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?
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.
(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.
(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!