mousemove and preventDefault()

[annevk]

Per https://bugzilla.mozilla.org/show_bug.cgi?id=1674658 and https://jsfiddle.net/zu0jpar2/ in particular this seems like some hacky way to prevent text selection in Chrome/Safari that does not work in Firefox. The specification just says that mousemove is cancelable, but doesn't describe what that means.

[saschanaz]

I feel it shouldn't be cancelable because, as a comment in the bug says, the mouse move itself can't be canceled.

[annevk]

Agreed, but that would require Chrome and Safari to change their implementation.

cc @rniwa @NavidZ

[NavidZ]

cc @mustaqahmed

[mustaqahmed]

We (Chromium) attempted to fix this behavior twice already, in 2015 and 2018! Compat problems forced us to revert in both cases!!

Interestingly, Safari didn't allow canceling mousemove until 2015 (or may be later), see the bug I linked above. Curious what motivated Safari to introduce this.

[saschanaz]

It seems the second revert was due to Chrome's internal use, though.

[mbrodesser]

According to the spec, a "mousemove" event has no default action. But a "mousedown" event has. For the former to be consistent with the latter, the former should get a default action consisting of extending a possibly started selection.

That would match Chrome's and Firefox's behavior when preventDefault() is not called. Firefox would then have to follow Chrome's behavior of not extending the selection when preventDefault() was called.

AFAIK, Safari's behavior is the same as Chrome's.

[saschanaz]

Seems the Firefox behavior has changed to match others 🙂

[mustaqahmed]

@saschanaz Your comment on Jan 13 is correct, and I convinced myself we should retry removing the mousemove default in Chrome! Do we know why Firefox decided to match Chrome???

[saschanaz]

I think it was per https://github.com/w3c/uievents/issues/278#issuecomment-777337460. I still think it's hacky and selectionchange should be preferred instead 🤔. @mbrodesser

[mbrodesser]

I think it was per #278 (comment).

Yes.

I still think it's hacky and selectionchange should be preferred instead thinking. @mbrodesser

Sure, this can be changed. I agree that it would be cleaner. @rniwa: any concerns from your side?

[rniwa]

I still think it's hacky and selectionchange should be preferred instead thinking. @mbrodesser

Sure, this can be changed. I agree that it would be cleaner. @rniwa: any concerns from your side?

Change what?

[mbrodesser]

I still think it's hacky and selectionchange should be preferred instead thinking. @mbrodesser

Sure, this can be changed. I agree that it would be cleaner. @rniwa: any concerns from your side?

Change what?

What's mentioned in https://github.com/w3c/uievents/issues/278#issuecomment-792846116.

[rniwa]

What does "removing mousemove default" mean in this context? Making preventDefault on mousemove a no-op?

[annevk]

Yeah.

[saschanaz]

We at Mozilla found that this is not web compatible since jQuery Mobile calls MouseEvent#preventDefault() on desktop browsers without expecting mousemove. We had to restore our previous behavior after getting regression reports.

We should probably prefer selectionchange event for this purpose and make mousemove not cancelable.

[justanotheranonymoususer]

@saschanaz so how does it work with other browsers such as Chrome? There's probably other behavior difference of Firefox vs Chrome beyond the cancelability of mousemove?

[saschanaz]

@saschanaz so how does it work with other browsers such as Chrome? There's probably other behavior difference of Firefox vs Chrome beyond the cancelability of mousemove?

A weird bug in Chrome prevents canceling mousemove default action when CSS transform: translate() is used elsewhere on the page. So some websites basically are depending on that bug, e.g. travador.com.

[mustaqahmed]

We at Mozilla found that this is not web compatible since jQuery Mobile calls MouseEvent#preventDefault() on desktop browsers without expecting mousemove. We had to restore our previous behavior after getting regression reports.

I got confused with this today after seeing that the WPT is passing in Chrome! I think this is because the test ends too early before catching the Chrome problem. Before I land the change, I wanted to double-check: @saschanaz you meant Mozilla now ignores mosuemove cancellation again, is this correct?

We should probably prefer selectionchange event for this purpose and make mousemove not cancelable.

Unfortunately, the selectionchange event is not cancelable! And I don't see any other candidate event that can possibly allow suppressing selection-extension.

[saschanaz]

Weird, not sure what happened exactly, but the test suddenly started to pass around October 2022 without any implementation change nor the test change. I wonder any test harness change affected it.

[saschanaz]

@jgraham might know what happened?

[jgraham]

Looks like it was actually fixed in July by https://bugzilla.mozilla.org/show_bug.cgi?id=1543337

[saschanaz]

That didn't touch testing/web-platform/meta/uievents/mouse/mousemove_prevent_default_action.tentative.html.ini, no?

[saschanaz]

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1804341

[mustaqahmed]

Looking back at this issue after a while, I get a partial picture about compat problems with two orthogonal default actions of mousemove:

• Chrome couldn't fix dragstart default action: https://bugs.chromium.org/p/chromium/issues/detail?id=346473#c34
• Mozilla couldn't fix selectionchange default action: https://github.com/w3c/uievents/issues/278#issuecomment-887490074

We need to check each event on Chrome, Firefox and Safari for a complete picture.

[saschanaz]

Just noticed @mustaqahmed's Intent to Ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/fyVzOAmQHzU, I guess we can close this issue once Chrome ships it successfully.

[mustaqahmed]

I agree we can close it. Chrome is shipping it on M125 (Stable to be released in ~a week), and the WPT is passing in all browsers.