web-facing PSA: preventDefault on mousemove is ignored in Chrome 43+

[Rick Byers]

I'm sending this retroactively for a bugfix I wasn't originally involved in because we're now seeing it has some web compat impact and so probably deserves some more discussion.  I don't think we want to hold Chrome 43 stable for this given that the impact appears relatively contained, but could be wrong.

Summary:

Prior to Chrome 43, if a mousemove event was cancelled by JavaScript we would not allow that movement to participate in default drag behaviors such as text selection and drag and drop.  This is in violation of the DOM events spec which says mousemove has no default action.  To suppress such default actions, applications should be calling preventDefault on mousedown instead (which avoids issues like what the behavior should be when some but not all mousemove events in a stream are cancelled).

Demo:

http://rbyers.net/eventTest.html

Attempt to select text with the 'call preventDefault for mousemove' option enabled and disabled.  Compare to changing the option for mousedown.

Behavior in other browsers:

Firefox: canceling mousemove has no impact, as per spec and new chrome behavior.

IE: canceling mousemove does not disable text selection but does disable drag-and-drop (IE team isn't aware of any good reason for this inconsistency).

Safari: cancelling mousemove suppresses drag and drop and text selection as in Chrome 42.

Known sites affected:

So far I'm only aware of a couple reports of affected behavior - see bugs blocked on the bug for this change.  However there's some risk that affected sites will regress only in mouse drag performance (eg. due to issues like this) and so people may not have noticed yet.  I expect to talk more with the Google Maps team about this today.

[Levi Weintraub]

Thanks for handling this, Rick!

FYI Rick rolled this change out here: https://codereview.chromium.org/1145433002/

[Nico Weber]

On Wed, May 13, 2015 at 7:10 PM, Levi Weintraub <le...@chromium.org> wrote:

Thanks for handling this, Rick!

FYI Rick rolled this change out here: https://codereview.chromium.org/1145433002/

So this is not changing in m43 after all then?

[Rick Byers]

On Thu, May 14, 2015 at 12:56 PM, Nico Weber <tha...@chromium.org> wrote:

On Wed, May 13, 2015 at 7:10 PM, Levi Weintraub <le...@chromium.org> wrote:

Thanks for handling this, Rick!

FYI Rick rolled this change out here: https://codereview.chromium.org/1145433002/

So this is not changing in m43 after all then?

Not clear yet, I've requested merge but it may be too late.  We're very close to shipping Chrome 43 to stable.  

The key bit of information that led me to roll this out is that Maps was required to rely on this behavior (behind a WebKit UA check) due to another long-standing mouse-event related bug in blink/WebKit.  I'm bumping the priority of that bug and once we've fixed it we will try to reland this fix, so discussion on this web-facing PSA is still useful.  There's a tricky tradeoff here between trying to rationalize our crufty mouse event behavior to be more interoperable and breaking sites that are using UA checks to work around WebKit-specific issues (as Maps was).

It's tempting to argue that we shouldn't try to fix any of these mouse event issues (we'll just cause more pain than benefit) and should instead rely on pointer events to clean this all up.  But even with pointer events it would be pretty awkward to rely on compat-hacks for mouse events while preserving rational behavior for pointer events (especially given our layered platform goals of eventually re-implementing mouse events on top of pointer events).