Specify a new document's URL

[jyasskin]

The "URL that was originally to be fetched" isn't clear about which URL
that actually is.

I believe the reasonable choices here are the following, of which I'm guessing browsers do the third, but I'm not very confident I've got this right:

• The request's URL: The original URL before any redirects.
• The request's current URL: The final URL after any redirects, and
  treating a Service Worker's response as from that URL.
• The response's URL: Either the final URL after any redirects, or, if a
  Service Worker intercepted the fetch and returned a response from a
  different URL, that different URL.

Fixes #3953.

I suspect this is tested in the Service Worker tests, but I haven't yet found the specific test. I'm sending this PR anyway in case you already know it is or isn't tested.

---

/browsing-the-web.html ( diff )
/infrastructure.html ( diff )

[annevk]

Yeah, I think that's correct. Note also that request can be null, e.g., for srcdoc, so that those wouldn't work universally anyway.

@wanderview usually has good insights on this so copying to get this checked twice.

[wanderview]

I'm pretty sure we do not use the service worker final response URL for the document URL. This was explicitly designed to allow a separate "offline" page to be loaded by service worker without changing the URL bar.

So I think its the second option, maybe?

[annevk]

Oooh right, it was different for navigations, indeed. Thanks! So yeah, it's the final request URL, but that also means there needs to be accounting here for callers such as srcdoc (and javascript: maybe).

[wanderview]

I would expect the document URL to remain about:srcdoc, about:blank, javascript: etc when a service worker controller is inherited from the parent.

[jyasskin]

@wanderview, do you know where the SW behavior is or should be tested? service-workers/service-worker/navigation-redirect.https.html looks like where I'd expect, but nothing there uses sw=fetch-url.

[jyasskin]

I've updated the change to use the "request's current URL", and the SW implication is now tested. srcdocs seem to be covered by https://github.com/web-platform-tests/wpt/blob/master/html/browsers/history/the-location-interface/location_hash.html#L24. javascript: URLs are mostly covered by https://github.com/web-platform-tests/wpt/blob/master/html/semantics/embedded-content/the-iframe-element/iframe_javascript_url_01.htm, and I'm adding a test for one more case in web-platform-tests/wpt#14316.

[jyasskin]

The behavior of javascript: URLs isn't spec'ed correctly... In https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigate, the 'If resource is a request whose url's scheme is "javascript"' steps initialize a variable named address to the iframe's old address, but that variable's never used. With this PR, I think we get Chrome's result by appending address to request's URL list, and I think we get Firefox's by doing nothing. What would you like me to spec?

[jyasskin]

The use of address here seems to have gone away in https://github.com/whatwg/html/pull/3946/files#diff-36cd38f49b9afa08222c0dc9ebfe35ebL82043, which led to @TimothyGu filing #3953, which this PR is trying to fix. :)

[domenic]

Probably also related: web-platform-tests/wpt#14262

[domenic]

This looks like a strict improvement to me from the current spec. @annevk, do you agree?

[annevk]

Yeah, thanks!

[domenic]

Oh wait, upon re-reading I realized we didn't actually answer @jyasskin's question about javascript: URLs:

With this PR, I think we get Chrome's result by appending address to request's URL list, and I think we get Firefox's by doing nothing. What would you like me to spec?

Based on the discussions in #1565 and https://bugzilla.mozilla.org/show_bug.cgi?id=1281375#c7 it sounds like Chrome's behavior is probably more web-compatible... Let's do that?

[jyasskin]

@domenic @annevk, I've specified what I think is Chrome's behavior in the most recent change.

[domenic]

Commented at https://bugzilla.mozilla.org/show_bug.cgi?id=836567#c55.