Intent to Ship: Create service worker client and inherit service worker controller for srcdoc iframe

[Chromestatus]

Contact emails

lz...@microsoft.com, yyana...@chromium.org

Explainer

None

Specification

https://github.com/w3c/ServiceWorker/issues/765

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

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?

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.

[Chris Harrelson]

Hi, comment below.

On Sun, Feb 9, 2025 at 10:52 PM Chromestatus <ad...@cr-status.appspotmail.com> 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?

 

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67a9a231.2b0a0220.2908d.03c1.GAE%40google.com.

[Yoshisato Yanagisawa]

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.com> 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 iframes without the sandboxing directives, allow-same-origin and allow-scripts, result in having the active service worker value of null as their origin is an opaque origin.

Will it work?

[Domenic Denicola]

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, 2018). 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. And 1.5 years ago we landed the big navigation and session history rewrite, which let Dom Farolino make a series of improvements 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 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 are included? I want to make sure we have at least that much coverage.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Yoav Weiss (@Shopify)]

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, 2018). 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. And 1.5 years ago we landed the big navigation and session history rewrite, which let Dom Farolino make a series of improvements 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 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 are included? I want to make sure we have at least that much coverage.

Friendly ping on this question! :)

[Liang Zhao]

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, 2018). 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. And 1.5 years ago we landed the big navigation and session history rewrite, which let Dom Farolino make a series of improvements 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 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 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 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.

[Yoav Weiss (@Shopify)]

LGTM1 to align on the defacto and desired behavior. (but please make sure that the relevant spec work does happen)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@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.

[Chris Harrelson]

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2Bah_d%2BSAWuxgRozzzw35yKZxvmNLD-6aLL6S%2BwoA257A%40mail.gmail.com.

[Mike Taylor]

LGTM3

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-K1chxn8Y6_t7u3%2BL84rJZmD%3DNXzEf3dQvc19pzayy5A%40mail.gmail.com.