On Wednesday, February 19, 2025 at 3:34:23 AM UTC-8 Yoav Weiss (@Shopify) wrote:
On Thursday, February 13, 2025 at 5:50:24 AM UTC+1 Domenic Denicola wrote: I'll refrain from giving formal LGTM to let more discussion settle, but I want to provide my API owner perspective that we should approve this without requiring the specification work to finish up. Specifying this is unfortunately very complex. There have been multiple attempts (2015 <https://github.com/whatwg/html/pull/322>, 2018 <https://github.com/whatwg/html/pull/3725>). Each time we have uncovered foundational issues in the HTML spec, or the service workers spec, or the interaction between them, which have made specifying the behavior rigorously difficult. Over time, we've made significant progress on these foundations, e.g. the original 2015 attempt spawned the introduction of the now-foundational "environment" concept <https://github.com/whatwg/html/pull/1776>. And 1.5 years ago we landed the big navigation and session history rewrite <https://github.com/whatwg/html/pull/6315>, which let Dom Farolino make a series of improvements <https://github.com/whatwg/html/pulls?q=is%3Apr+is%3Aclosed+author%3Adomfarolino+about%3A> to the srcdoc iframe specification in general. I'm optimistic that we could now specify the behavior described in this Intent! ... With significant effort. And Monica, the new service worker spec editor, has recently indicated interest <https://github.com/whatwg/html/pull/3725#issuecomment-2638146186> in taking on that effort! But I don't think we should block on that. The desired behavior has been known since 2015, and Firefox and Safari have mostly aligned on it. I think we should aim for a good balance of effort and interop, by: - Putting extra effort into landing an exhaustive test suite, as part of this intent - Updating Chromium to conform to that test suite, by approving this intent - And then, asynchronously, focus on getting the spec updated, and getting all browsers to converge on the edge cases that the test suite uncovers. *Regarding the test suite, can the Intent authors confirm that all the cases from this 2017 test suite PR <https://github.com/web-platform-tests/wpt/pull/4610> are included?* I want to make sure we have at least that much coverage. Friendly ping on this question! :) Yes, all the cases of* this 2017 test suite PR <https://github.com/web-platform-tests/wpt/pull/4610> *are covered by newly added wpt tests, and more. The added tests are at https://wpt.fyi/results/service-workers/service-worker/srcdoc-iframe.https.html. Also updated chromestatus with the added tests link. On Wednesday, February 12, 2025 at 12:24:24 PM UTC+9 Yoshisato Yanagisawa wrote: Hi Chris, Thanks for the reply. 2025年2月12日(水) 3:56 Chris Harrelson <chri...@chromium.org>: Hi, comment below. On Sun, Feb 9, 2025 at 10:52 PM Chromestatus <ad...@cr-status.appspotmail.c om> wrote: Contact emails lz...@microsoft.com, yyana...@chromium.org Explainer None Specification https://github.com/w3c/ServiceWorker/issues/765 This is an issue and not a specification. Is the srcdoc change in behavior here landed in the service worker specification? That is true. I found the following: https://w3c.github.io/ServiceWorker/#control-and-use-window-client Especially, Note: Sandboxed <https://html.spec.whatwg.org/multipage/iframe-embed-object.html#attr-iframe-sandbox> iframe <https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-iframe-element>s without the sandboxing directives, allow-same-origin and allow-scripts, result in having the active service worker <https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-active-service-worker> value of null as their origin <https://html.spec.whatwg.org/multipage/browsers.html#concept-origin> is an opaque origin <https://html.spec.whatwg.org/multipage/browsers.html#concept-origin-opaque> . Will it work? Summary Srcdoc context documents are currently not service worker clients and not covered by their parent’s service worker. That results in some discrepancies (e.g. Resource Timing reports the URLs that these document load, but service worker doesn’t intercept them). This aims to fix the discrepancies by creating service worker clients for srcdoc iframes and make them inherit parent's service worker controller. Blink component Blink>ServiceWorker <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EServiceWorker%22> TAG review None TAG review status Not applicable Risks Interoperability and Compatibility There are basic consensus on spec discussion to make srcdoc iframes inherit parent's service worker controller: - https://github.com/w3c/Service Worker/issues/765 - https://github.com/whatwg/html/pull/2809 - https://github.com/whatwg/html/pull/3725 - https://github.com/web-platfor m-tests/wpt/pull/4610 and Firefox/Safari are already passing basic tests: - https://wpt.fyi/results/service-workers/service-worker/ about-blank-replacement.https.html?label=experimental&label=master&aligned ("Nested about:srcdoc is controlled and ..." subtest). While - The actual spec PRs are not yet merged/finalized. - There are minor behevior differences regarding to sandbox attribute interaction ( https://chromium-review.googlesource.com/c/chromium/src/+/ 6085871/comment/5e2b64cc_e0e5b3f1/) it's still beneficial to make Chromium catch up, to provide the basic consistent behavior across browsers. *Gecko*: Shipped/Shipping (https://wpt.fyi/results/servi ce-workers/service-worker/about-blank-replacement.https. html?label=experimental&label=master&aligned) Passing basic WPT tests. *WebKit*: Shipped/Shipping (https://wpt.fyi/results/servi ce-workers/service-worker/about-blank-replacement.https. html?label=experimental&label=master&aligned) Passing basic WPT tests. *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 With this feature, the srcdoc iframe and service worker interaction can be debugged the same way as other iframes. When it is controlled by a service worker, all the normal Service Worker APIs like navigator.serviceWorker.controller work for the frame the same way as other frames, and service worker APIs like clients.matchAll() work the same way for this type of clients. 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 Basic test at https://wpt.fyi/results/service-workers/service-worker/ about-blank-replacement.https.html?label=experimental&label=master&aligned As part of the feature work, we are adding a new srcdoc-iframe.https.html test in the same folder. Flag name on about://flags None Finch feature name ServiceWorkerSrcdocSupport Requires code in //chrome? False Tracking bug https://crbug.com/41411856 Estimated milestones Shipping on desktop 135 Shipping on Android 135 Shipping on WebView 135 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/featu re/5128675425779712?gate=5164246479142912 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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/ch romium.org/d/msgid/blink-dev/67a9a231.2b0a0220.2908d.03c1.GAE%40google.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67a9a231.2b0a0220.2908d.03c1.GAE%40google.com?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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1845551d-cf76-43c8-aaab-121299b1a49bn%40chromium.org.
