LGTM3 On Monday, March 9, 2026 at 11:37:00 AM UTC-7 [email protected] wrote:
> Thanks for digging into spec question, Hubert. > > LGTM2, contingent on WPTs landing (to Yoav's point). > > Best, > > Alex > > On Monday, March 9, 2026 at 7:45:27 AM UTC-7 Hubert Chao wrote: > >> Following up, we've convinced ourselves that this fix is actually >> adhering to the current spec. Specifically, inside the navigate step >> <https://w3c.github.io/ServiceWorker/#client-navigate:~:text=HandleNavigate%3A%20Navigate%20browsingContext%20to%20url%2C%20using%20browsingContext%E2%80%99s%20associated%20document%2C%20with%20exceptionsEnabled%20true.> >> it >> says: >> >> HandleNavigate: Navigate browsingContext to url, using browsingContext’s >> associated document, with exceptionsEnabled true. >> >> where browsingContext is the ServiceWorkerClient context (link >> <https://w3c.github.io/ServiceWorker/#client-navigate:~:text=Let%20browsingContext%20be%20this%E2%80%99s%20browsing%20context.>), >> >> and not the service worker's browsing context. >> >> We've also consulted with navigation-dev@, and think the impact of this >> is limited to the LNA check (see >> https://groups.google.com/a/chromium.org/g/navigation-dev/c/HAVTdd4NpBc) >> >> >> On Thu, Feb 19, 2026 at 2:12 PM Hubert Chao <[email protected]> wrote: >> >>> >>> >>> On Wed, Feb 18, 2026 at 10:59 AM Rick Byers <[email protected]> wrote: >>> >>>> On Wed, Feb 11, 2026 at 10:03 AM Hubert Chao <[email protected]> >>>> wrote: >>>> >>>>> On Tuesday, February 10, 2026 at 8:42:40 PM UTC-5 [email protected] >>>>> wrote: >>>>> >>>>> Is any spec update (https://wicg.github.io/local-network-access) >>>>> needed to reflect this change or is this behavior implied by what's >>>>> already >>>>> there? >>>>> >>>>> >>>>> I added a quick update to it just now (meant to do it yesterday but >>>>> got sidetracked). See >>>>> https://wicg.github.io/local-network-access/#issue-f5cf3665 >>>>> >>>> >>>> Normally our bar for spec work is that an algorithm is described >>>> precisely somewhere, whether in the official spec, a monkey patch spec >>>> like >>>> this or a PR. Normally an open issue would not be considered sufficient >>>> for >>>> an I2S. With firefox now implementing, I assume there'd be support for >>>> getting spec changes landed in the HTML spec, is that right? To what >>>> extent >>>> are you / your team actively engaged in driving the upstream spec work for >>>> LNA? >>>> >>> >>> Driving spec changes is something that is on the team's roadmap; we'd >>> intended to be further along but other work to stick the launch has been >>> taking time away from this (most notably splitting the permissions >>> <https://chromestatus.com/feature/5068298146414592> and adding more >>> enterprise policies(rollout step 4 in here >>> <https://chromestatus.com/feature/5152728072060928>)). >>> >>> Interestingly enough, the spec might already state the behaviour I'm >>> proposing for this I2S. Checking with others to see if I'm reading it wrong >>> or not. >>> >>> >>>> Not having WPTs for this increases the interoperability risk (e.g. >>>>> Increases the probability that Firefox folks forget about this particular >>>>> part). >>>>> Can you bump up the priority of adding these WPTs? >>>>> >>>> >>>> +1, now that Firefox is shipping WPTs are really essential (or we >>>> should assume there will be interop issues). >>>> >>> >>> Agreed, we've been talking with Firefox about this as well. >>> >>> /hubert >>> >> -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/21814f5e-f104-418b-a808-1eab5382c1acn%40chromium.org.
