Thanks Patrick.  I agree we should get something spec'd around this and try to make blink match the spec. Patrick, did you come across this on any real-world sites (to motivate priority)?

Treating all about: the same as about:blank seems reasonable to me, but I'd want to understand why Safari changed.  Domenic this is HTML, right?

Just guessing that this is controlled mainly by loader code?  Perhaps there's no code change here anyway, just a spec change so the component won't much matter.

I discovered this when looking at giftcards.com, which is using about:this for an iframe in their newsletter sign up flow. Haven't checked for other outstanding issues with the same root issue.

As far as I can tell the behavior in these tests is governed, per spec, by whether those pages are same-origin or cross-origin. A document's origin is detailed in https://html.spec.whatwg.org/multipage/browsers.html#origin .

For about:blank, in particular the "initial 'about:blank' document" case, so it shares the origin with its creator. So it's definitely same-origin.

For about:foo.... it appears we fall back to "If the Document was obtained in some other manner", although it's not clear that's intentional. In which case it goes to an opaque origin, so it's cross-origin per spec.

Given the 2/2 browser split, and the fact that this impacts at least one real-world site, I think it'd be reasonable to align about:foo with about:blank in the spec. Although I am a little surprised that e.g. Firefox allows modifying about:config, see https://jsbin.com/mumuvif.

If we decide to go the other way and change Chrome and Firefox to make about:foo cross-origin, we should at the very least clarify that this is intentional in the spec's fallback case.

Whichever way we decide, we need some web platform tests for this case :)

It appears this changed in WebKit in https://github.com/WebKit/webkit/commit/90426dd303e878a4e6b433a8852e35a66334e9c9

CCing some people from Apple and Mozilla for their thoughts. It sounds like if we were to go with about:foo being same-origin, WebKit's thoughts are most important to get, as Edge seems interested in changing to same-origin based on this bug report.

about:foo and about:config do the same exact thing in Firefox in this case: result in a network error and the load not actually happening.  So the actual URI of the document in that iframe is still the original about:blank, which the page can modify.  The same thing would happen for a load denied by CSP, by the way.

In terms of the spec as currently written, we start off with https://html.spec.whatwg.org/multipage/browsers.html#navigate and end up in step 12.  At this point "resource" is not a response, its url's scheme is not "javascript", there are no applicateion caches, but the scheme _is_ a "fetch scheme" (why the heck do we have an explicit scheme whitelist here???).

So we go to https://html.spec.whatwg.org/multipage/browsers.html#process-a-navigate-fetch and in step 6 go to https://fetch.spec.whatwg.org/#concept-fetch

In fetch, we go to https://fetch.spec.whatwg.org/#concept-main-fetch and in step 12 discover our mode is "navigate" and go to https://fetch.spec.whatwg.org/#concept-basic-fetch

In basic fetch, we see the scheme is "about" and the path is not "blank", so return a network error.

Now all this unwinds back to https://html.spec.whatwg.org/multipage/browsers.html#process-a-navigate-fetch and we set "response" to the the error response, then proceed to step 7 and later.  I _think_ in this case there is no "location URL" on the response, so we end up in step 13 and go to https://html.spec.whatwg.org/multipage/browsers.html#process-a-navigate-response

In process-a-navigate-response, we have a network error, so we jump to https://html.spec.whatwg.org/multipage/browsers.html#read-ua-inline which is supposed to show a network error page with a unique origin.  

It's not clear to me how compatible all this is with what browsers actually do.  What happens in various browsers right now if you have a subframe, load some page in it, then try to navigate it to a URL CSP blocks?  And note that if I'm reading all this right, typing "about:config" in the URL bar is not supposed to work at all, which doesn't so much match implementations.

I filed https://github.com/whatwg/html/issues/2414 on the about:config thing and https://github.com/whatwg/html/issues/2415 for the general issue of interaction of CSP/etc with navigation not being interoperable in UAs in various ways.

Thanks Boris, that's a much more comprehensive spec reading.

It seems like for about:foo:

- Firefox and Chrome block the navigation (as if it were a 204, or apparently a CSP-denied load)
- Edge displays a network error page
- Safari displays a blank page

I'm not sure whether the origins of Edge/Safari are unique opaque origins or if they might be same-origin with other about:foo pages; that's a separate set of tests. But Edge and Safari are both either spec compliant or close to it.

It sounds like for web compat, at least in this giftcards.com case, Chrome and Firefox's behavior is desired.