LGTM1 to align on the defacto and desired behavior. (but please make sure that the relevant spec work does happen)
On Wed, Feb 19, 2025 at 7:01 PM 'Liang Zhao' via blink-dev < blink-dev@chromium.org> wrote: > > > 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.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 > <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/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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1845551d-cf76-43c8-aaab-121299b1a49bn%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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2Bah_d%2BSAWuxgRozzzw35yKZxvmNLD-6aLL6S%2BwoA257A%40mail.gmail.com.
