WindowClient.navigate() behavior for reserved clients and in-flight navigations

[aliams]

Reading through the spec, it wasn't immediately clear what should happen when navigate() is called on a reserved client (which could be going through a navigation) or even a client that has an in progress navigation. Chatting with @mattto, it sounds like we should cancel the in-progress navigation and replace it with the new navigation. I would liken this to someone who is in the middle of a navigation when they change course via the address bar.

cc spec editors @jakearchibald and @jungkees

[wanderview]

Over here I proposed rejecting with InvalidStateError:

#1034 (comment)

I think implementing anything active like this on reserved clients could be difficult and racy. One of the reasons we thought it was ok to add reserved clients was that it could be lightweight and effectively implemented by pre-allocating a UUID. If we require this kind of cancellation behavior it gets a lot harder to implement IMO.

[jungkees]

When windowClient.navigate() is called, I think it's much later than we can cancel the previous navigate attempt. (We're queuing a task to make this navigate.) That said, I agree to @wanderview's suggestion here.

[aliams]

So, in essence, a navigation that is in progress should always get to complete (regardless of the client type)? Only after a completed navigation do we allow a navigate() call without rejecting it with an InvalidStateError?

[wanderview]

So, in essence, a navigation that is in progress should always get to complete (regardless of the client type)?

Well, it could be stopped through other means. I just think of a "reserved" Client object as an inert placeholder. The only thing you can really do with it is queue up messages via postMessage().

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

[aliams]

Ok so to recap, reserved clients cannot and should not have the ability to be navigated. Clients (not reserved) that are half-way through a navigation will not perform a new navigation until the in-flight navigation is complete.

[jungkees]

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 #1123 (comment). 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 on it.

[aliams]

In that case, should we be more explicit about the behavior of navigate() for non-reserved clients? Specifically, what happens to in-flight navigations?

[jungkees]

The synchronous part of navigate algorithm checks whether it'll abort its own steps or go ahead after aborting the active document of the browsing context. I think client.navigate() isn't different from other call sites like location.assign(), etc. Am I misunderstanding your point?

[jakearchibald]

F2F: This is no longer a problem as we aren't going to expose reserved clients. If a client is navigated while it's navigating, it should behave like iframes do in the same situation – tests should assert this. I assume that the latest navigation happens and the old aborts, as long as the new client hasn't been created yet.

Use case: You serve something online-first, but it gets stuck after headers & some body. You want to start again, switching to an offline-first model. Client navigation gets you this.