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/CAHEiSH3UoCMDdwjP%3DWwA2BmYvH_L%3D47A7YrT9gDD_WCs05_4wg%40mail.gmail.com.
