Web-Facing Change PSA: Interoperable mousedown event cancellation in iframe

[Mustaq Ahmed]

Contact emails

mus...@chromium.org, fla...@chromium.org

Specification

None

Summary

Make mouse event targets agnostic to mousedown event cancellation when the pointer is dragged out of an iframe. When the mouse is dragged out of an iframe, all browsers (including Chrome) send mousemove and mouseup events to the iframe. However, if the mousedown event is cancelled, Chrome today maintains an old WebKit exception that mousemove and mouseup events are sent to the outer frame. WebKit removed this exception last year, and Mozilla never showed this behavior in recent years. This feature will remove the Chrome-only exception for this special case.

Blink component

Blink>Input

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This change will make Chrome fully interoperable with Firefox and Safari. We don't expect many compat problems from this change as this is a desktop focused special case in which Chrome is different from other browsers. I.e. we would expect users to see the issues in other browsers already. The compat risk is non-zero, however it is difficult to measure whether the change to the frame target changes would be breaking without exposing the change.

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=262691)

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/uievents/mouse/cancel-mousedown-in-subframe.html?label=experimental&label=master&aligned

Flag name on chrome://flags

None

Finch feature name

MouseDragFromIframeOnCancelledMouseDown

Requires code in //chrome?

False

Tracking bug

https://crbug.com/269917

Sample links

https://mustaqahmed.github.io/web/interop/cancel-mousedown-in-iframe-top.html
https://codepen.io/mustaqahmed/full/yLjBraJ

Estimated milestones

Shipping on desktop

122

Shipping on Android

122

Shipping on WebView

122

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5083240891416576

This intent message was generated by Chrome Platform Status.

[Tai Huynh]

Hi all! Thanks for posting this discussion. 

My name is Tai, and I'm an engineer at Webflow. Just wanted to comment that this change triggered a regression in our Designer editor. 

Our application architecture involves rendering the design editor within an iframe and surrounding it with tools in the main document, some of which overlay the iframe to facilitate direct on-canvas manipulation. A feature affected by this update is our Grid overlay tool, which allows users to drag and drop elements into different grid cells directly on the canvas. 

Previously, our users could start a mousedown event within the iframe (e.g. selecting an element to move) and drag it to an overlay in the main document (e.g. our Grid overlay), where the mouseenter event on the overlay would fire, allowing them to drop the element into a new grid cell.  After the update, the mouseenter event on the overlay no longer fires when the mouse event starts within the Iframe. This prevents the grid overlay feature from recognizing elements being dragged into it, which breaks the drag-and-drop experience. Users can no longer effectively place elements into specific cells of the grid, limiting the usability of our design tool.

I've attached a simple html file that outlines this issue that you can test on version 121 vs the latest

We're not sure how to handle this issue in this case, and I'm sure we're not the only apps that have a similar architecture and workflow. Can you help guide us towards a solution to address this spec-compliant change?

Thank you,

Tai

[Yoav Weiss (@Shopify)]

Hey Tai!

Thanks for reporting this! Would you mind opening up an issue on crbug.com, indicating the breakage and providing clear reproduction steps (e.g. with the HTML you attached here)?

One more question worth addressing in the issue - do you see the same issues with Firefox and/or WebKit's current behavior?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/61591a88-1ce1-4d8d-830a-e9390069bbc1n%40chromium.org.

[Tai Huynh]

Hi Yoav,

I'll go ahead and submit the the issue on crbug.com. We see the same issue with Firefox and in Safari, but it's a bit unclear to us when this change shipped, since a large portion of our users use Chrome and we do a significant of our development on Chrome, so it wasn't surfaced to us. We definitely know that it had been working at some point when we originally built our feature though. 

Interestingly, we encountered a similar issue in Webkit earlier this year, which seems to have been reverted or fixed recently ~> https://github.com/WebKit/WebKit/pull/24919. 

Thank you,

Tai

[Tai Huynh]

I submitted the ticket here ~> https://issues.chromium.org/issues/327409885. 

Thank you! 🙇🏻‍♂️

Tai

[Chris Harrelson]

Thanks Tai!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/71eb8467-cee4-4d91-b03e-53c1bf6a2d1fn%40chromium.org.

[Mustaq Ahmed]

Thanks Tai for the detailed bug.  I will look into it shortly.

> Interestingly, we encountered a similar issue in Webkit earlier this year, which seems to have been reverted or fixed recently ~> https://github.com/WebKit/WebKit/pull/24919. 

This WebKit change seems unrelated: it is about dragging into an iframe (not "out of an iframe"), and it makes WebKit match Chrome.