I submitted the ticket here ~> https://issues.chromium.org/issues/327409885.
Thank you! 🙇🏻♂️ Tai On Wednesday, February 28, 2024 at 10:05:59 AM UTC-8 Tai Huynh wrote: > 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 > On Wednesday, February 28, 2024 at 9:06:56 AM UTC-8 Yoav Weiss (@Shopify) > wrote: > >> 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? >> >> >> >> On Tue, Feb 27, 2024 at 10:39 PM Tai Huynh <anht...@gmail.com> wrote: >> >>> 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 >>> >>> On Tuesday, January 9, 2024 at 12:40:32 PM UTC-8 Mustaq Ahmed wrote: >>> >>>> Contact emailsmus...@chromium.org, fla...@chromium.org >>>> >>>> SpecificationNone >>>> >>>> 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 componentBlink>Input >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EInput> >>>> >>>> TAG reviewNone >>>> >>>> TAG review statusNot 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 >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ?Yes >>>> >>>> >>>> https://wpt.fyi/results/uievents/mouse/cancel-mousedown-in-subframe.html?label=experimental&label=master&aligned >>>> >>>> >>>> Flag name on chrome://flagsNone >>>> >>>> Finch feature nameMouseDragFromIframeOnCancelledMouseDown >>>> >>>> Requires code in //chrome?False >>>> >>>> Tracking bughttps://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 >>>> <https://chromestatus.com/>. >>>> >>> -- >>> 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 >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/61591a88-1ce1-4d8d-830a-e9390069bbc1n%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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+unsubscr...@chromium.org. 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.
