Re: [w3c/ServiceWorker] WindowClient.navigate() behavior for reserved clients and in-flight navigations (#1123)

> I support we could be more explicit about this by creating a ReservedClient interface that avoids exposing methods like navigate, focus, etc.

We could just use the `Client` interface but rather wanted to expose as much information as possible. It seems having the `.reserved` state and explicitly throwing on `navigate()` and `focus()` look good to me.

> reserved clients cannot and should not have the ability to be navigated.

Right.

> Clients (not reserved) that are half-way through a navigation will not perform a new navigation until the in-flight navigation is complete.

@aliams Ignore my comment in https://github.com/w3c/ServiceWorker/issues/1123#issuecomment-296575097. I think that's wrong. The reason why we don't want to navigate a reserved client would be because it can be in an invalid state to trigger a navigate: it doesn't have a global yet, not associated with a browsing context yet, etc.

`windowClient.navigate()` for non-reserved clients should be allowed. A client being a non-reserved client means the client's global object is already set to the [[WindowProxy]] of the browsing context. I think we can invoke [navigate](https://html.spec.whatwg.org/multipage/browsers.html#navigate) on it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1123#issuecomment-296877299