clarify creation URL when initial about:blank is replaced

[wanderview]

So, I'm not sure if there is a spec problem or not. I am having a hard time figuring out the creation URL situation for frames where an initial about:blank is replaced with a loaded document.

AFAICT, the creation URL is set to about:blank in step 6 here:

https://html.spec.whatwg.org/#set-up-a-browsing-context-environment-settings-object

I think maybe its then overridden to the final URL in navigate at step 4:

https://html.spec.whatwg.org/#process-a-navigate-fetch

Although I am confused about the difference between settings and environment here.

I guess what I really want to understand is:

1. Is the creation URL on an environment (inner window in gecko terms) ever considered about:blank?
2. Is the creation URL on the environment then updated to the actually loaded document?

Related to this is setting the environment/settings execution ready.

3. In the about:blank replacement case is the environment marked execution ready twice? One for the about:blank and once for the loaded document URL?

[annevk]

Sorry that this is all still a mess. I got stuck addressing it last time and gave up for a while, focusing on other things. Mainly what we need here and for similar issues is: 1) what do browsers do? 2) tests 3) what would the ideal processing model look like?

[wanderview]

I can comment a bit on gecko's current state.

Gecko does not track an explicit "creation URL" on the environment. Instead we get the current document and inspect its original URI. We track the documents original URI vs whatever pushState() might have changed it to.

So this mostly matches what happens in step 6 here:

https://html.spec.whatwg.org/#set-up-a-browsing-context-environment-settings-object

I think the main difference we have is that when we re-enter those steps to replace the initial about:blank we don't preserve the original about:blank creation URL like step 5.1 suggests. (If I understand what a reserved environment is in that algorithm correctly...)

If we changed 5.1 to use the creation URL from the new document then it would match what gecko does.

I'm not really sure how the step 6 navigate setting of creation URL comes into play in gecko. In our code navigating sets the URL on our network channel and then on the document. We then effectively use the document URL as the creation URL as described above.

The end result of all this is that you can have an environment that gets an about:blank creation URL and then shortly thereafter changes to its loaded document creation URL.

[wanderview]

Again, for context, this is getting exposed to content script via the service worker spec'd Client.url. Its spec'd to return the environment's creation URL. I'm not sure that spec was written with about:blank replacement in mind, though.

[jungkees]

@wanderview, we need to improve this part of the algorithms for sure, but here's the PR that I made to introduce the reserved client (environment) concept for your reference: #1776.

Also, I'd like to note that I'm working on another related PR (#2080) to specify the service worker inheritance for iframes. It's now blocked on the corresponding tests: web-platform-tests/wpt#4610. I hope we can continue further discussion with this change merged (or at least have it in mind.)

[jungkees]

Although I am confused about the difference between settings and environment here.

We defined an environment as a base struct of an environment settings object. But a navigation is the only place where it starts as an environment. For other client creation cases, an environment settings object is created directly.

I guess what I really want to understand is:

1. Is the creation URL on an environment (inner window in gecko terms) ever considered about:blank?

As the navigation is the only place where it starts with an environment, it's never initialized to about:blank. The initial about:blank document or any document having a URL must have been loaded in the browsing context on which this navigation was triggered. So, the reserved client (environment)'s creation URL is set to the request's URL (current) or should be changed to be set to the empty string (as you suggested.)

2. Is the creation URL on the environment then updated to the actually loaded document?

If we initialize the creation URL to the request's URL, then it should remain. Else, if we initialize it to the empty string, it think we should add a step that sets its value to the document's URL when the document is created.

Related to this is setting the environment/settings execution ready.

3. In the about:blank replacement case is the environment marked execution ready twice? One for the about:blank and once for the loaded document URL?

In this case, the settings object that is marked the execution ready is reused for the new document. So, the second marking is a no-op. I'm not quite sure what the expected behavior should be here, but it won't make sense that the settings object is changed back to reserved state in any case though, right?

[jungkees]

As the navigation is the only place where it starts with an environment, it's never initialized to about:blank. The initial about:blank document or any document having a URL must have been loaded in the browsing context on which this navigation was triggered. So, the reserved client (environment)'s creation URL is set to the request's URL (current) or should be changed to be set to the empty string (as you suggested.)

Actually, if the request's URL is about:blank (i.e. not an initial about:blank but navigate to about:blank), the creation URL is initialized to about:blank.

FYI, this navigation to about:blank is not going through http fetch and thus doesn't get a controller (active service worker). But if this navigation was done on an iframe, #2080 suggests it still inherits the controller from its parent, if it has one.

[wanderview]

Is the creation URL on an environment (inner window in gecko terms) ever considered about:blank?

As the navigation is the only place where it starts with an environment, it's never initialized to about:blank. The initial about:blank document or any document having a URL must have been loaded in the browsing context on which this navigation was triggered. So, the reserved client (environment)'s creation URL is set to the request's URL (current) or should be changed to be set to the empty string (as you suggested.)

So, I was not asking about reserved Client specifically here. I just want to understand the environment case where there is an initial about:blank document that is replaced with a loaded document. This is independent of how we expose things in Clients API.

If we initialize the creation URL to the request's URL, then it should remain. Else, if we initialize it to the empty string, it think we should add a step that sets its value to the document's URL when the document is created.

Consider, though, what is the creation URL when the environment has the initial about:blank document but the navigation has not started/completed? Is it "about:blank"? We can't set the loading document's creation URL on the environment yet because we don't know if it will redirect, etc.

In this case, the settings object that is marked the execution ready is reused for the new document. So, the second marking is a no-op. I'm not quite sure what the expected behavior should be here, but it won't make sense that the settings object is changed back to reserved state in any case though, right?

Yes, it makes sense to me that the second one is mostly a no-op. Except, it seems the creation URL might change from about:blank to the loading document's URL.

[jungkees]

I just want to understand the environment case where there is an initial about:blank document that is replaced with a loaded document. This is independent of how we expose things in Clients API.

In the current status, the environment's creation URL is not considered about:blank except the case when the loaded document is about:blank document. I'm not defending this behavior. I'd want to discuss and come up with a desired behavior. Checking what we discussed in w3c/ServiceWorker#1034 (comment), the environment's creation URL might have to be initialized to the empty string and later set to the final URL of the navigate fetch.

Consider, though, what is the creation URL when the environment has the initial about:blank document but the navigation has not started/completed? Is it "about:blank"?

In the current spec as-is, the creation URL of the environment is nothing but the request's URL. As just mentioned in the above paragraph, I think we should change it to the empty string and the final URL for when the client is in the reserved state and in the execution ready state, respectively.

To be precise, "when the environment has the initial about:blank document" isn't a possible case I guess. An environment is not associated with any document until it gets one during a navigation. The initial about:blank document that will be replaced by the loaded document is associated with a separate environment settings object that will be reused for the loaded document.

We can't set the loading document's creation URL on the environment yet because we don't know if it will redirect, etc.

Yes, in the navigation case, we'd need to set the creation URL of the environment settings object to the final URL when the navigate fetch is done and before marking it as execution ready.