Fallback base URL computation for a document with about:srcdoc but not an iframe srcdoc document

[tkent-google]

Demo: http://jsfiddle.net/int32_t/oztck57e/5/
Bug report from a web author: https://crbug.com/875642

Specification link 1: https://html.spec.whatwg.org/multipage/dynamic-markup-insertion.html#document-open-steps Step 11.3
Specification link 2: https://html.spec.whatwg.org/multipage/urls-and-fetching.html#fallback-base-url

The demo page has three nested documents,

• Top
  • iframe srcdoc doc1
    • iframe about:blank doc2

According to the specification, doc2's URL will be about:srcdoc by doc2.open(). See specification link 1. After that, fallback base URL computation for doc2 returns about:srcdoc because the document is neither an iframe srcdoc document nor about:blank. See specification link 2.

Chrome currently follows the specification. So relative URLs in doc2 can't be resolved.
Firefox throws an exception on doc2.open(). So doc2's URL is not changed.
Safari's behavior is not understandable. But anyway the base URL of doc2 is the URL of the top document.

Proposal:
I'd like to change the specification so that doc2 has the top document URL as the fallback base URL in this case. For example, changing

2. If document's URL is about:blank,

to

2. if document's URL is about:blank or about:srcdoc,

in https://html.spec.whatwg.org/multipage/urls-and-fetching.html#fallback-base-url

[annevk]

cc @TimothyGu @bzbarsky

[bzbarsky]

It really feels like we should not have documents whose URL is about:srcdoc that are not srcdoc documents... It causes problems of all sorts, not just this.

[tkent-google]

yeah, tweaking document.open() is also an option.

[domenic]

Are there other ways to cause documents to have about:srcdoc URLs, besides document.open()? If that's the only one, then probably we should fix it. And now's the time to do so, as we're making other changes/alignments in that area.

[tkent-google]

I have no idea about other ways to set about:srcdoc to an existing document.

"URL and history update steps" is used by pushState(), but I think about:src is rejected by security checks in Step 7 of pushState() and replaceState()

[annevk]

location.reload() is also special cased. I suspect document.open() being able to do this was an oversight.

[bzbarsky]

Are there other ways to cause documents to have about:srcdoc URLs, besides document.open()?

A javascript:'hello' iframe in a srcdoc document? Gecko doesn't implement the spec behavior for using the url of the page the javascript: url comes from for the url of the resulting document so far, so that hasn't bitten us yet.

[domenic]

I wonder if we should port the

Compare newURL to document's URL. If any component of these two URL records differ other than the path, query, and fragment components, then throw a "SecurityError" DOMException.

check into the URL and history update steps generally. I guess that would make document.open() throw in this case; perhaps we want it to no-op instead.

This would also impact blob: and data: URL-derived documents. (I believe those can be same origin... haven't checked.)

the spec behavior for using the url of the page the javascript: url comes from for the url of the resulting document

I wasn't able to find this in the spec.

[domenic]

I wonder if we should port the [...] check into the URL and history update steps generally.

On further reflection this seems unlikely to work. There is probably lot of code that does things like

const win = window.open("about:blank");
win.document.open();
win.document.write("<a href='/foo'>");
win.document.close();

and expects the relative link to work. With my "I wonder..." proposal the relative link would instead of fail to resolve relative to about:blank.

So, we are back to either a guard against about:srcdoc in the document open steps, or fixing the fallback URL computation.

[bzbarsky]

I wasn't able to find this in the spec.

Hmm. The spec used to define something here (I can't find old versions well enough on my current network to look up what), but now https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigating-across-documents step 13 javascript: case substep 13 just creates a Response with no obvious URL. And then https://html.spec.whatwg.org/multipage/browsing-the-web.html#process-a-navigate-response does:

Any Document created by these steps must have its URL set to the URL that was originally to be fetched, ignoring any other data that was used to obtain the resource.

which is definitely not what used to be going on there; here used to be an "override URL" and whatnot.

It's possible that that URL was the URL of the Document that the evaluation happens in, not of the one where the URL came from. But the current spec doesn't seem to do either one, afaict...

[semoal]

Any solution related to this?

[annevk]

@bzbarsky it was removed as part of #3946. I recall pointing that out as a potential problem, but I cannot find me doing so.

To take a step back here, we have various things that affect state of documents and it would be really good to have a consistent story. All the state that is expected to be copied onto about:blank documents should probably also be copied once document.open() is invoked. (Currently the latter is lacking referrer and referrer policy for instance, and maybe CSP.)

And then we have certain special URLs that we generally do not want to leak (e.g., via referrer) that we perhaps should avoid copying over as a somewhat general policy. So that if you have a data: URL document with an <iframe> the base URL of that <iframe> does not become the full data: URL.

At a high-level this would make sense to me, but I don't think I have the bandwidth right now to drive all the necessary changes and tests.

[bzbarsky]

it was removed as part of #3946

Er... why would that commit have changed the behavior of javascript: loads??? If it did, that's a bug in the commit and we should fix it, no?

All the state that is expected to be copied onto about:blank documents should probably also be copied once document.open() is invoked.

Possibly, yes. It's a little hard to say what semantics people expect out of document.open....

[annevk]

@domenic @TimothyGu do you remember why you removed the "override URL" concept in #3946 despite it also affecting javascript: URLs? I cannot find our prior conversation about it.

[domenic]

@TimothyGu may recall better, but my best attempt at recollection was that we did a bit of testing and found it was Gecko-only. Don't hold me to that though.

Edit: the linked PR says

This PR also removes the "overridden reload" algorithm and related concepts, which were previously only implemented in Firefox and Edge, causing developer confusion evident in https://bugzilla.mozilla.org/show_bug.cgi?id=556002.

[bzbarsky]

That's talking about the document.open() case. But in the javascript: case, what's the Chrome/Safari behavior? The Gecko behavior is to give the new document a javascript: URL. The spec behavior with override URL was to give it the URL of the document that started the navigation. The current spec behavior is, I think, to give it the URL of the document the javascript: evaluation happened in. What does Chrome implement and why? And what happens with base URLs? In Gecko, the base URL definitely comes from the document that started the navigation, because that was needed for web compat. In Chrome, I haven't quite figured out whether it's using the base URI of the document the evaluation happened in or something else...

[bzbarsky]

(And to be clear, this was a use of override URL that had nothing to do with "overridden reload" and which also got removed!)

[bzbarsky]

The current spec behavior is, I think, to give it the URL of the document the javascript: evaluation happened in.

Er, no, the current spec behavior is unclear to me. https://html.spec.whatwg.org/multipage/browsing-the-web.html#initialise-the-document-object says to use the URL of the request if there is a request, otherwise to use the URL of the response. But in this case https://html.spec.whatwg.org/multipage/browsing-the-web.html#read-html doesn't pass a request or a response to those steps, though we might assume it's at least passing the response handed to <https://html.spec.whatwg.org/multipage/browsing-the-web.html#process-a-navigate- response>. That response has no URL, though, in the javascript: case, and the only request around is the one with the javascript: URL, so if you do the reading between the lines the spec says to use a javascript: URL for the document? That behavior is Gecko-only and the override thing was precisely to do something that matched other browsers more closely...

[TimothyGu]

I think I understand the concern here. I reviewed my notes and chat logs but I can't find anything that specifically talks about javascript: URLs, so I must've either conflated "overridden reload" with "override URL", or not understood the historical context of

That behavior is Gecko-only and the override thing was precisely to do something that matched other browsers more closely...

A PR to restore the concept of "override URL" solely for the purpose of javascript: URLs would seem correct. If anyone would want to see the original version, it is available at https://whatpr.org/html/3946/c5eda3f/browsing-the-web.html#override-url

[domenic]

Thanks @TimothyGu. I guess what would be most correct would be to test browsers and figure out what they do, and write extensive tests, but failing that, restoring us to a non-broken spec would be a good idea, yeah.

/cc @natechapin in case he has also looked at this aspect of javascript: URLs.

[bzbarsky]

A PR to restore the concept of "override URL" solely for the purpose of javascript: URLs would seem correct.

I agree. Thank you for the link to the old spec text: that pretty clearly says that the result of a javascript: evaluation gets the URL of the document it was evaluated against, not of the document that started the navigation (as I said above). I think that matches the Chrome behavior, in my limited testing.