What to do with non-srcdoc about:srcdoc documents

[domenic]

Continued from #3989. In that issue, it was noted that you can use document.open() to create a document whose URL is about:srcdoc, but is not an iframe srcdoc document. (Because document.open() will set document's URL to the entry global's document's URL.)

I think it might also be possible to do this with javascript: URL navigation, starting with a srcdoc document and then replacing it with a new non-srcdoc document, that keeps the about:srcdoc URL.

I think we have three options here:

1. Redefine "an iframe srcdoc document" to be "has a URL that matches about:srcdoc", so we don't have two slightly-different concepts. This is not a big change, from what I can tell:

   • Various minor impacts on document conformance requirements
   • Impacts on parser behavior, but only in the "initial" insertion mode, which I think is not reachable after document creation?
   • Impacts on referrer determination. This is the big testable difference.

2. Prevent these scenarios from arising, e.g. by making document.open() skip the URL-change step if it would change the URL to one that matches about:srcdoc, and preventing navigation to javascript: URLs from srcdoc documents.

3. Accept that this is fine.

Note that Blink seems to do something similar to (1) already: https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:third_party/blink/renderer/core/dom/document.cc;l=3346;drc=1b9ee37d9e583adb8b4f492115bdb8fd268e8188;bpv=1;bpt=1 although it only handles the document.open() case, not the javascript: URL case.

[domfarolino]

Impacts on referrer determination. This is the big testable difference.

Just to make sure we're on the same page, the difference here would be that the referrer for requests made inside of non-srcdoc about:srcdoc documents would be about:srcdoc (the document's URL), whereas for "srcdoc documents" it would be whatever parent document's URL is obtained from the "While" loop in "Determine request's referrer", right?

Chrome seems to do (1) not just for document.open() but also for javascript: URLs, per my testing the behavior described in the above paragraph. I think where Chromium does this is here: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/loader/frame_loader.cc;l=1064-1071;drc=2d584aba6c742f3d4e7b1e7f8ea29ec334ec4477. I also tested Firefox & Safari Tech Preview for these cases (document.open() and javascript: URLs) and found that Firefox completely agrees with Chrome in both cases. For Safari, I can't get javascript: URL navigations to work (create a new document) in iframes regardless of srcdoc-ness, and in the document.open() case I observe no referrer being sent at all for any requests in the document, which just seems wrong. (The Origin header is the parent's origin though).

I'm personally a fan of (1); the distinction between about:srcdoc and srcdoc documents always seemed a little weird to me. Outside of these weird corner cases, the about:srcdoc URL is non-navigable, and since I don't see a reason for these weird edge cases to behave differently than "the true srcdoc document," the distinction seems unimportant to maintain, and at least two implementations agree completely.

[domenic]

Just to make sure we're on the same page, the difference here would be that the referrer for requests made inside of non-srcdoc about:srcdoc documents would be about:srcdoc (the document's URL), whereas for "srcdoc documents" it would be whatever parent document's URL is obtained from the "While" loop in "Determine request's referrer", right?

Right.

Chrome seems to do (1) not just for document.open() but also for javascript: URLs, per my testing the behavior described in the above paragraph. I think where Chromium does this is here:

This code doesn't seem to copy over the "is srcdoc document" bit from what I can see. But, I guess if it works, including across browsers, then we should be good!

I'd be happy with (1) then. We should write WPTs for the referrer determination in both the document.open() and javascript: URL cases. And ideally we'd run those tests against a Chromium version that removes is_srcdoc_document_ entirely in favor of having Document::IsSrcdocDocument() return whether the document's URL IsAboutSrcdocURL().

[domenic]

It'd be good to run those WPTs in cases involving about:srcdoc?bar#foo as well. (Where the URL changed via history.replaceState().)

[domfarolino]

This code doesn't seem to copy over the "is srcdoc document" bit from what I can see. But, I guess if it works, including across browsers, then we should be good!

Yeah, just for completeness I think how this works is: (1) blink::Document gets its bit from the document initializer here, and (2) the initializer gets its bit from the loader, and (3) the loader gets its bit from whether the actual URL that the new URL has is simply about:srcdoc here.

I'll work on web platform tests and a spec change, and look into modifying the Chromium implementation.

[domfarolino]

I've posted https://chromium-review.googlesource.com/c/chromium/src/+/4690242 for the basic tests, but I'm really running into trouble with replaceState()/pushState() inside about:srcdoc documents. Chrome just won't let me do it, and Safari also won't let me do it, but changes its error message depending on whether I do:

• history.replaceState(null, '', '?foo'); or
• history.replaceState(null, '', 'about:srcdoc?foo')

In the latter case, Safari's console error message just thinks that the iframe is sandboxed for some reason.

So maybe it's not possible to end up with an about:srcdoc Document whose URL is any different than about:srcdoc? I figured we'd at least be able to do simple hash modifications through location.href = '#foo'; but even those are evaluated against the non-about:srcdoc URL, and are instead evaluated against the parent's URL (or maybe the "about base URL" technically, not sure) and cause a full-on cross-document navigation! newly-added about base URL of course, which is a snapshot of the parent's URL.

[domfarolino]

I just learned about https://html.spec.whatwg.org/#can-have-its-url-rewritten-dev, which seems to explain this. Well, at least the algorithm does. I suppose this table could use more about:srcdoc examples. So yeah, I think the WPTs I mentioned above are all we can do.

[domfarolino]

Hmm, actually it appears that Safari correctly allows hash mutations to srcdoc documents via history.replaceState(null, '', 'about:srcdoc#foo');. You just can't use a query parameter or a relative URL, because the former is rejected by the "can have its URL rewritten" algorithm and the latter resolves against the snapshotted parent about base URL.

Chrome incorrectly disallows this because of this code it seems.

[domfarolino]

I've updated the tests in web-platform-tests/wpt#41066 to test the history.replaceState() scenario.

Now for the spec change to actually close this issue out, I'm thinking we can:

1. Introduce the "matches about:srcdoc" concept, similar to "matches about:blank" but a little tighter as described below
2. Make the existing "an iframe srcdoc document" definition just a thin layer over "matches about:srcdoc"

This will leave us with three related concepts:

• about:srcdoc, the unresolvable URL that we explicitly use when creating srcdoc documents, and maybe reference in a few more places
• "matches about:srcdoc", which does a similar comparison to "matches about:blank" but asserts the query is null, since as discussed above in this thread, it seems not possible to create an about:srcdoc document with null query¹
• "an iframe srcdoc document" which is just an alias for a document whose URL "matches about:srcdoc" above; this concept seems like a nice thin grammatical convenience to keep around in some places

I'll start down this route.

Footnotes

1. The only reason this is possible with about:blank is because we can window.open() about:blank?foo documents, which we can't do for srcdocs. ↩

[domenic]

I figured we'd at least be able to do simple hash modifications through location.href = '#foo'; but even those are evaluated against the non-about:srcdoc URL, and are instead evaluated against the parent's URL (or maybe the "about base URL" technically, not sure) and cause a full-on cross-document navigation! newly-added about base URL of course, which is a snapshot of the parent's URL.

FYI I think you'd be able to do location.href = "about:srcdoc#foo" inside a srcdoc document? I'm not sure though.