consider Client behavior for windows where initial about:blank is replaced with a loaded document

[wanderview]

Our current plan is to expose the environment creation URL as Client.url when the environment is marked execution ready. This is a bit confusing for the case where the environment has multiple documents; like when an initial about:blank is replaced with a loaded document. See:

whatwg/html#2456

My read of the spec and my initial implementation so far expose the about:blank URL briefly as Client.url. In addition, the environment is marked execution ready twice. Once as about:blank and once as the final loaded URL. The second time its marked execution ready this basically amounts to updating the creation URL.

Is this intended behavior for the clients API? I suspect perhaps the intent was not to mark the Client as non-reserved until after the final loaded document is execution ready.

[wanderview]

I suspect perhaps the intent was not to mark the Client as non-reserved until after the final loaded document is execution ready.

Talking with @bzbarsky, it may be very hard to determine if an initial about:blank will indeed be followed up another document. And I don't think we can just ignore about:blank completely because programmatically constructed iframes are supposed to inherit their parent's service worker controller, etc. We need to represent them as Client objects.

[jakearchibald]

In this iframe / window.open / _blank with empty url case where replacement can happen:

• client: the about:blank doc
• reserved client: null
• target client: null

Following the navigation, the client will be the same as the about:blank document.

[wanderview]

@jakearchibald, I'm kind of confused by #1091 (comment). I don't recall this being the outcome from the f2f meeting.

I thought we said we were going to do:

• client: the client initiating the load just like we do for non-replacement cases
• reserved client: the client currently attached to the about:blank window
• target client: I don't remember, but the about:blank window would make sense to me.

If you don't want the existing about:blank to be "reserved" since its already execution ready, we could also do:

• client: the client initiating the load just like we do for non-replacement cases
• reserved client: null
• target client: I don't remember, but the about:blank window would make sense to me.

So in:

// foo.html
let f = document.createElement('iframe');
document.body.appendChild(f);

f.contentWindow.someGlobalStatus = 'yuck';

f.src = 'frame.html';

I guess I would always expect FetchEvent.clientId to reference the foo.html parent window here.

It also seems to make sense to make FetchEvent.targetClientId reference the current about:blank iframe client.

I can go either way about whether FetchEvent.reservedClientId should be null or the iframe client. I guess from an implementation point of view null would be slightly more convenient for me.

@smaug---- also was wondering what we do if replacement load is for a download. The example he gave was:

win = window.open(); win.document.body.innerHTML = "<a href='http://download.me.com/foo.zip'>zip</a>"

In this case, if someone clicked the link I would expect:

• the .clientId to be the about:blank window (since its an anchor tag),
• the reserved client to be null (if we decide to go that way above)
• the target client to be the about:blank window since we don't know yet if it will download

If it was <a download> then I would expect the target client to be null.

[wanderview]

Although, I still wonder how devs can use this API if we don't provide a consistent place for them to find "the client that will exist if this navigation succeeds". If we don't provide the about:blank initial window as the reserved client, then devs have to do some complicated logic to determine they are in this weird replacement case.

[wanderview]

I read through the meeting minutes and it seems we did not really come to conclusion here.

I need to do something for our implementation, though, so I'd like to make a sketch proposal we can discuss at the next meeting. Hopefully I will have something implemented behind a pref so we can try it out.

My idea is to be more explicit about the replacement case. Instead of putting the about:blank client ID in the FetchEvent.reservedClientId we expose it in a new FetchEvent.initialClientId.

I took the term "initial" here from the "initial about:blank document" used in the HTML spec. I also considered replacementClientId, but I think that's confusing because in other navigations the targetClientId is usually being replaced by the reserved client. When there is an initial about:blank we are actually not replacing the client, but reusing it. The document is getting replaced (but a client is not the document).

So for this code snippet:

// foo.html
let f = document.createElement('iframe');
document.body.appendChild(f);

f.contentWindow.someGlobalState = 'yuck';

f.src = 'frame.html';

The FetchEvent would have:

• clientId = foo.html window
• reservedClientId = null
• initialClientId = about:blank iframe window
• targetClientId = about:blank iframe window

After frame.html loads it has the same client id as the initial about:blank iframe.

[wanderview]

By the way, about:blank replacement windows are in theory already exposed, even without reserved Client ID. Consider this page:

<iframe src="frame.html" id="frame"></iframe>
<script>
var f = document.getElementById('frame');
f.contentWindow.foo = 'foo'
</script>

here the .foo global is set on the initial about:blank window. This window is then reused when "frame.html" loads. The "frame.html" page will see .foo on its global.

Consider if "frame.html" is delayed in loading. Perhaps a service worker purposefully does this. In this case:

1. A clients.matchAll() should theoretically return a Client for the initial about:blank before the load completes because it is same origin.
2. A later clients.matchAll() should then return the same Client for the "frame.html" window (because it got reused).

I'm intending to write a test for this, but I'm unsure if I should upstream it to WPT yet or not. What do people think?

[jungkees]

I'm intending to write a test for this, but I'm unsure if I should upstream it to WPT yet or not. What do people think?

IMO, we might want to put a 'do not merget yet' tag on the test until we come to a conclusion. Or, you can just share the test through the firefox code search if that's more convenient?

[wanderview]

I'll post the test once I have it written. Its revealing more problems for me that I'm trying to work through.

One thing that I have noticed is that service workers may have exposed some browser optimizations that were not observable before.

Consider loading a simply <iframe src="foo.html"></iframe>. Per the spec this should create an initial "about:blank". At least in gecko, though, we don't actually do this since nothing tries to access .contentWindow. This allows us to save some work when nothing has interacted with the frame before the load completes.

With service workers, though, we can do this:

1. Intercept foo.html and delay the response
2. Do a clients.matchAll() to observe the initial about:blank

In this case our optimization to avoid creating the initial about:blank is exposed because step (2) won't find a Client. At least with our current Clients implementation anyway.

I'm trying to make this work without forcing a de-opt in the general case. I'm trying to make our code create the initial about:blank on demand when clients.matchAll() would have observed it.

[jungkees]

@wanderview, I think I should catch up a bit but in #1091 (comment):

clientId = foo.html window

clientId for the snippet should be the about:blank client. clientId in my mental model is the request's client's id. When the src attribute of the iframe's set, foo.html's nested browsing context is navigated instead of the top-level browsing context. See https://html.spec.whatwg.org/#otherwise-steps-for-iframe-or-frame-elements step 4. That is, the request passed to fetch will use the iframe's settings object as the client.

I'm a bit concerned about introducing initialClientId. It seems it goes too much complex for corner cases. Coming back to the definition we originally thought:

• client: request's client
• reserved client: literally reserved client for main resource
• target client: to-be-replaced client

For normal case (i.e. navigate from non-initial document), they seem to be apparent.

For replacement case, I think they should be:

• client: about:blank
• reserved client: reserved environment for frame.html request (this is different from the f2f decision)
• target client: null (or event about blank?)

As this is the case where the existing global (and the environment settings object) are legitimately reused, the reserved client being removed and the client being the final client for the resource sounds good to me.

FYI, whatwg/html#2080 is the related PR that I should revisit now.

[jungkees]

FYI. I tested the snippet in #1091 (comment) on Chrome. It doesn't seem to reuse the existing window of about:blank document. The state set to the global object is lost after the navigation.

[wanderview]

FYI. I tested the snippet in #1091 (comment) on Chrome. It doesn't seem to reuse the existing window of about:blank document. The state set to the global object is lost after the navigation.

Yes, I did some compat testing and @bzbarsky pointed out the only real use where browsers maintain compat is this:

<!doctype html>
<!-- top.html -->
<html>
<body>
<!-- declaratively defined iframe -->
<iframe src="nested.html" id="nested"></iframe>

<script>
// Modify the iframe's global synchronously before it loads.  The resulting nested.html
// iframe will have its `window.foo` property set even though we are applying it to
// initial about:blank document here.
let frame = document.getElementById("nested");
frame.contentWindow.foo = "foo";
</script>

</body>
</html>

What do you think the various properties on FetchEvent should be for this situation?

[jungkees]

That's right. I confirmed by testing Chrome reuses the global in the case shown in your previous comment.

What do you think the various properties on FetchEvent should be for this situation?

To my understanding, the declaratively-defined-iframe case and the snippet in #1091 (comment) go through the same flow according to the spec. I think the properties on FetchEvent should be the same. That is:

• client: about:blank
• reserved client: reserved environment for nested.html request (this is different from the f2f decision)
• target client: null (or even about:blank?)

So, devs will see two different clients (about:blank and reserved env) exist during the fetch, which is what's happening indeed. And when the resulting document is installed, the about:blank client is reused and the reserved client is abandoned. (If the navigate found a matching active service worker, that property should be overwritten to the client.)

[wanderview]

reserved client: reserved environment for nested.html request (this is different from the f2f decision)

Do you mean a new reserved client that is different from the about:blank initial document client? Which client does the final document end up with?

Either way you are suggesting that the client ID for a global change during its lifetime. That seems like a bad invariant to break.

And all of this is observable to the service worker. Consider this:

<!doctype html>
<!-- top.html -->
<html>
<body>
<!-- declaratively defined iframe -->
<iframe src="nested.html" id="nested"></iframe>

<script>
let frame = document.getElementById("nested");
frame.contentWindow.navigator.serviceWorker.postMessage(evt => {
  // do stuff and post back to the service worker
  evt.source.postMessage(someMsg);
});
</script>

</body>
</html>

A clients.matchAll() can get and postMessage() to the initial about:blank. Of course the final window is also accessible as well. I think the service worker could get confused if the MessageEvent.source.id changes over time for the same global.

I understand this is complex, but this is the cost of exposing the browser's underlying window/global model via a primitive API like Clients. The about:blank replacement complexity is already there. The primitive needs to reflect that to be honest about what is really happening.