mousemove event should be cancelable, see D3E spec: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-mousemove
Created attachment 576366 [details] [diff] [review] Patch This patch doesn't change actual behavior, just changes as cancelable. IE9 and Opera support cancelable mousemove event. However, on both of them, :hover state isn't prevented even if I prevents default of mousemove event. And also, text selection isn't blocked by the default prevented mousemove event. WebKit's mousemove event is not cancelable.
Btw, I'm not sure if this is just a bug in D3E. DOM 2 mousemove is not cancelable.
Comment on attachment 576366 [details] [diff] [review] Patch You did send email to the mailing list, but did you perhaps file a spec bug? Clearing r? until we know what to do with this.
I filed a spec bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17626
In Blink, it seems that this bug is fixed. https://src.chromium.org/viewvc/blink?revision=157207&view=revision https://codereview.chromium.org/23463012 https://code.google.com/p/chromium/issues/detail?id=261449 I confimed this in Chromium 31.0.1624.0 (221710)(Blink 537.36 (@157356)).
Also, the spec bug has been resolved from way back.
Any progress? Chrome and IE are consistent with D3E, and Firefox still with D2E. Hmm... now I see that Firefox have correct behaviour a long time ago: https://bugzilla.mozilla.org/show_bug.cgi?id=76929 << contains a good testcase
Created attachment 8411624 [details] [diff] [review] Patch Okay, let's take this into 31 which is next ESR.
Why should mousemove be cancelable?
Comment on attachment 8411624 [details] [diff] [review] Patch Ah, hmm, selection handling might in theory need this.
(In reply to Olli Pettay [:smaug] from comment #9) > Why should mousemove be cancelable? For the odd spec change... We discussed about this in the last D3E meeting, though.