Navigate improvements

[annevk]

Improvements I'd like to make to the navigate algorithm:

• Redo the "resource" argument. Introduce a "destination record" concept (a URL record, session history entry, request, or response) and make it clear that the "destination" argument is one of those. (The word "resource" trips up the server folks and there's no reason to use it here, especially with such a narrow definition.) Note that the only case I found for supporting session history entries has been the "entry update" concept which this could replace. It's conceivable we could maybe update an entry without doing the whole navigate dance. Not sure I care personally in which order that is figured out.
• Put "Initialising a new Document object" in its own distinct algorithm separate from navigate and make it more clear what arguments need to get passed to it. Probably give it a section of its own.
• We need to have a response variable set to null early on (before "Fragments:") that can be updated by various concepts along the way.
• "Handle redirects:" should only jump to "Fragments:" for non-HTTP(S) scheme URLs and should at least set response to a network error for an attempt to redirect to a javascript URL. For HTTP(S) scheme URLs the HTTP-redirect fetch defined in Fetch needs to be used. Parsing the Location header needs to be abstracted and coordinated with Fetch (I might favor a special response that has an additional field to store the parsed result). Other than data URLs it seems Firefox supports no other schemes here either, but my testing has not been exhaustive (mailto, facetime, about). (Navigate doesn't appear to handle redirects properly #461)
• The navigate algorithm steps from the step that starts with "Resource handling:" onward should be its own algorithm so that multipart/x-mixed-replace (though is that still supported?) can invoke it directly. Should probably first check multipart/x-mixed-replace is still a thing. Now Remove navigation support for multipart/x-mixed-replace resources #1353.
• If we don't merge the two places that initialize a navigated document, make sure to rename "implement the sandboxing" per The fullscreen enabled flag is not set for the initial about:blank document in an iframe? #1385 (comment).

[annevk]

Another thing that needs to be done is to reduce the number of places that allocate a document object and initialize it. #1408 is a first step towards making them more similar.

[annevk]

We need to have a response variable set to null early on (before "Fragments:") that can be updated by various concepts along the way.

While this is true, we also use resource for this. So if we also started using a response this would become somewhat confusing.

We might just have to extract the bit starting at "Fragments" into its own algorithm somehow so that directs (anything else?) can invoke that with different arguments later on...

[annevk]

Below is an attempt at a more general "initialize" algorithm we could share between navigation and browsing context creation.

To initialize a browsing context /bc/ and document /document/, given ???:

1. Let window be null.
2. If /bc/'s session history's only entry is a Document object whose "initial about:blank flag" is set, then set window to that Document object's Window object.
3. Otherwise:
   1. Set window to a new Window object.
   2. InitializeHostDefinedRealm() ...
   3. New environment...
4. Set window's associated Document object to document.
5. Implement the sandboxing for document.
6. Other document state, this seems to come from: response / "creator"?

The problem is really this last step. In the case of initial about:blank (is that a flag on the document btw?) state seems to come from a creator (and not all such state is defined at the moment, e.g., HTTPS state). What about non-initial about:blank? What about blob URLs? What about data URLs? What about <iframe srcdoc>? We seem to define state of those things in various places throughout the standard, but the haphazard way in which it is done guarantees issues.

[annevk]

The initialize setup above is broken. We cannot create a document before we have a global to create one in.

I suspect what we need to do is pull out creating an global. Move that up and share it with create a browsing context.

Then have something to create a document. Again, try to make that an algorithm that both navigate and create a browsing context can use.

Then, hook up the document to the global. Can maybe be combined with previous step.

Then, for the navigate case, dispatch to the various algorithms that tell how to parse the HTML / handle the image / display the error / etc. and let those fill in the remaining document details.

[annevk]

Latest thoughts:

1. Per How to handle URL schemes that are not understood during navigation #1446 we need to handle unknown URL schemes later, asynchronously. That means step 9 and 12 can go away and we can remove the "gone async" concept.
2. Redirects no longer need to jump back to "Fragments". Instead, depending on the response's location URL we need to do these things:
   • Use "HTTP-redirect fetch" from Fetch for HTTP(S) schemes
   • Use normal Fetch for "fetch schemes" (about, blob, http(s), ftp, ...); ideally this feeds back into the original fetch invocation, but it might be simplest to just end up invoking it twice... Little bit worrisome with regards to state and such.
   • Turn the javascript URL scheme into a network error
   • Unknown URL schemes path for other schemes (either prompt or inline error)
3. We should only invoke Fetch for requests whose URL has a "fetch scheme"
4. We only have the resource immediately available if it is a response
5. The javascript URL scheme can only be found on a request

[annevk]

#1445 handles the document bit. I guess that leaves turning "resource" into an actual argument for this bug. I should probably attempt once more and see where it breaks down.

[annevk]

Closing this issue as at this point it's more confusing than helpful to me. Resource is an actual argument now, although I suppose we could further improve the definition of its type at some point.