should Client.navigate() reject on uncontrolled clients?

[wanderview]

Currently step 4 here:

https://w3c.github.io/ServiceWorker/#client-navigate

Requires that the Client.navigate(url) method reject if its called a Client that is not controlled by the current service worker.

What is the purpose of this restriction?

I believe an origin could easily use Client.postMessage() and then modify window.location. AIUI this is the same rationale why we don't require interaction for navigate(). Is this restriction legacy from before includeUncontrolled:true?

This came up because we were not aware of this spec step and I tried to fix the WPT in web-platform-tests/wpt#8743.

[twiss]

[From https://bugzilla.mozilla.org/show_bug.cgi?id=1430999]

The reason I'd like this restriction to stay is the following: I'm trying to implement code signing of web applications using Service Workers. Basically, the SW checks all responses from the server, and also the new SW file when an updatefound event is fired. Under this security model, when the new SW runs, it is not yet trusted (until the old SW asynchronously checks it) and shouldn't be allowed to navigate the client.

I know this is not the kind of thing the SW spec was designed for, but the spec does actually fit this use case if implemented carefully, and I'd be really grateful if it stayed thusly — I think it's a relatively important use case.

[jakearchibald]

Hmm, I think we should lift the restriction and perhaps look at some way of opting back into it.

If we want to expose the clients API to all pages, this is going to get in the way.

[twiss]

Hmm, I think we should lift the restriction and perhaps look at some way of opting back into it.

Right. Perhaps the client could call preventDefault() in the beforeunload event? Showing at least a dialog would be an improvement for my use case, although it's unfortunate that the web app would have no way of informing the user what's going on, especially if it detects that the new SW is unsigned (and therefore presumed malicious).

It doesn't work today in Chrome and Firefox because:

Blocked attempt to show a 'beforeunload' confirmation panel for a frame that never had a user gesture since its load. https://www.chromestatus.com/feature/5082396709879808