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. 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 <chris...@chromium.org>: > >> Hi, comment below. >> >> On Sun, Feb 9, 2025 at 10:52 PM Chromestatus < >> ad...@cr-status.appspotmail.com> wrote: >> >>> Contact emails lz...@microsoft.com, yyanagis...@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/ServiceWorker/issues/765 - >>> https://github.com/whatwg/html/pull/2809 - >>> https://github.com/whatwg/html/pull/3725 - >>> https://github.com/web-platform-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/service-workers/service-worker/about-blank-replacement.https.html?label=experimental&label=master&aligned) >>> >>> Passing basic WPT tests. >>> >>> *WebKit*: Shipped/Shipping ( >>> https://wpt.fyi/results/service-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/feature/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/chromium.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/9373ed56-dc48-4603-9d1c-2225b9923ab7n%40chromium.org.
