Use "matches about:blank" and "matches about:srcdoc" in more places

[domfarolino]

Right now step 19.5 in https://html.spec.whatwg.org/#navigate and step 2 in https://html.spec.whatwg.org/#fallback-base-url directly compare a url to about:blank. There are two interesting points here:

• HTML thinks fetch defines about:blank but it doesn't (see https://html.spec.whatwg.org/#about:blank)
• The matches about:blank algorithm exists and is used in a few places, but not these two places.

Maybe these two instances about should use it as well? I've looked through the other references of about:blank and I think they're fine, so these two are the only ones that need to be evaluated. And a couple of tests wouldn't hurt.

---

In this bug we should also consider the "matches about:srcdoc" definition that was recently added in #9534.

[domenic]

I'm quite sure they should use "matches about:blank". Adding WPTs at the same time we fix this would be good.

#816 tracks the missing definition. Probably at this point HTML should just define it?

[domfarolino]

I made #9558 to handle the "matches about:blank" side of this issue, but after evaluating whether we should use "matches about:srcdoc" more often, I've tentatively determined the answer is no. Consider the following places where "about:srcdoc" definition:

1. Navigate to "about:srcdoc" in the iframe processing model: N/A
2. determine navigation params policy container
   • This is called for (a) the response-is-non-null navigation case, (b) the about:srcdoc navigation case, and (c) the usual create navigation params by fetching case. The first two will never rely on the "matches about:srcdoc" distinction, and the latter doesn't apply for about:srcdoc navigations at all, so "no" is my answer to this one
3. determine the origin:
   • Almost the same as the above. No uses rely on the distinction the new definition provides, due to either being used directly in the synthetic about:srcdoc response case, the response-is-non-null case, or create nav params by fetching
4. #navigate's "if matches about:blank or is about:srcdoc" condition: no, because we cannot invoke #navigate with a URL that matches about:srcdoc that isn't exactly about:srcdoc, in the non-fragment-navigation case
5. constructing a synthetic response whose URL is about:srcdoc: N/A

If we agree on that, then I think once #9558 lands we can close this.

[domenic]

Are you sure you cannot #navigate to about:srcdoc?foo? I think it works per spec, and in Chrome too: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=11880

[domfarolino]

How does it work per spec? We wouldn't hit the srcdoc case in https://html.spec.whatwg.org/#attempt-to-populate-the-history-entry's-document step 5.1, right? I think we'd end up in https://fetch.spec.whatwg.org/#concept-scheme-fetch and get a network error and fail the navigation. If that's correct, maybe you still have a point though since the document state would still be around, and maybe its "origin" should contain the parent origin for the srcdoc case? Not sure

[domenic]

I meant that it makes it to the navigate algorithm. Then, what path it goes down from there, depends on our decision to use "is" vs. "matches". If we use "is", we get a network error. (Like Firefox??) Whereas if we use "matches", I think the algorithm blows up because there's no documentResource? And neither of those matches Chrome, from what I can tell, and I haven't tested Safari.

[domenic]

After some discussion on Matrix, it seems I was confused about what would happen if we use "matches".

We should probably continue to us "is" because there's a documentResource iff the URL is exactly about:srcdoc, and keeping those things in sync seems important. So I'm happy with the above analysis.

It would be ideal to find or add some web platform tests for the navigation-to-about:srcdoc?foo case before finally closing this issue.

[domfarolino]

It would be ideal to find or add some web platform tests for the navigation-to-about:srcdoc?foo case before finally closing this issue.

From a quick look I'm not finding any tests that assert about:srcdoc?foo is truly unresolvable, so I wrote web-platform-tests/wpt#41209 to add this. With this ready to land, I'm thinking we can close this but I'll let you do the honors if you agree.