search

whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
8.01k stars 2.62k forks source link

Is about:srcdoc a navigable URL? It doesn't seem so... mostly #6316

Closed domfarolino closed 3 years ago

domfarolino commented 3 years ago

Consider this site: https://browsing-context.glitch.me/iframe-srcdoc-test.html

It does the following:

  1. Sets up an initial <iframe srcdoc></iframe>
  2. After the outer window loads, we set iframe.srcdoc = ... to a document that does some console logging, and prompts the user to click a button
  3. Clicking the button sets iframe.contentWindow.location = [a page on the server].html, thus navigating the iframe away from the srcdoc contents
  4. The destination site attempts to navigate the iframe back to the about:srcdoc URL, thus reloading the srcdoc attribute contents as the iframe's content document.

In Chrome + Safari, (4) succeeds, successfully navigating the iframe (back) to the document described by the srcdoc attribute value. In Firefox Nightly, this completely fails with "Hmm. That address doesn’t look right.Please check that the URL is correct and try again".

As per https://html.spec.whatwg.org/multipage/urls-and-fetching.html#about%3Asrcdoc, the about:srcdoc URL is "unresovable", which is backed up by the fact that this URL is never "handled" (treated with an appropriate locally-created response) anywhere in the navigation algorithms. In fact the only time it ever seems to be handled is in the process the iframe attributes algorithm, which from my reading is not invoked when a non-srcdoc's window is navigated via window.location = [...] (the test case site above).

Given this, I think it makes sense to file bugs against Chrome + Safari here, however this is really subtle stuff so I wanted to get a second opinion /cc @domenic who has been looking at similar things with me, and @annevk in general.

For what it is worth, I caught this happening in a Chromium code review adding a referrer policy test that ensures srcdoc iframes inherit the right referrer policy when none is specified otherwise.

annevk commented 3 years ago

Yeah, I would expect 4 to network error. (The way this happens is that HTML's navigate asks fetch and fetch can only handle "blank" for the "about" scheme so it returns a network error.)

(See also #5867.)

domenic commented 3 years ago

The destination site attempts to navigate the iframe back to the about:srcdoc URL

In particular, it does window.location = 'about:srcdoc'. I agree this should fail.

If it did history.back(), then it should potentially succeed or fail, depending on bfcache...

domfarolino commented 3 years ago

If it did history.back(), then it should potentially succeed or fail, depending on bfcache...

Thanks, that's exactly what I was thinking. In that case I'll file bugs on Chrome + Safari about handling this navigation.

ArthurSonzogni commented 3 years ago

FYI I tried in the past restricting about:srcdoc navigations (~1y ago), but I had to quickly revert most of this:

In particular, same-document navigation must continue to be supported inside about:srcdoc.

This will result in an URL of about:srcdoc#anchor

History navigation toward about:srcdoc is supported in Chrome & Firefox. I double checked this was working independently of a potential backforward cache. I tested Firefox 87. Proof

Contrary to what is said above, this is implemented in every web browser, so it won't be easy to remove this feature without breaking websites.

antosart commented 3 years ago

I created some web platform tests here https://github.com/web-platform-tests/wpt/pull/28540. I think at least those should pass.

domenic commented 3 years ago

Yeah, anchor navigation should work (it never reaches fetch). And those tests look good, @antosart.

domfarolino commented 2 years ago

Hmm, I think anchor navigations inside about:srcdoc Documents will actually reach fetch. It seems that follow the hyperlink step 9 will parse the URL relative to the iframe srcdoc's node document, and the base URL for these documents is just the parent document's base URL (aka URL), which means the anchor navigation will actually result in navigating away from the about:srcdoc Document, if I understand correctly. This also is documented by https://bugs.chromium.org/p/chromium/issues/detail?id=974300#c2, and behaves properly on both Chrome and Firefox.

location.href += #anchor should indeed perform a same-document navigation though, and this works on both Chrome and Firefox and is appears to be spec-compliant.

domfarolino commented 2 years ago

History navigation toward about:srcdoc is supported in Chrome & Firefox. I double checked this was working independently of a potential backforward cache.

The "independently of potential backforward cache" part is really interesting to me. @ArthurSonzogni are you saying that even if the about:srcdoc document is not in the BFCache, back-navigations to about:srcdoc would still succeed (even though "explicit" navigations to about:srcdoc would fail)?

ArthurSonzogni commented 2 years ago

@domfarolino. Not really. I said every kind of about:srcdoc navigation are supported in Chrome. For instance:

  1. explicit cross-document navigation toward about:srcdoc iframe.contentWindow.location = "about:srcdoc" (see tests results)
  2. cross-document history navigation toward about:srcdoc.
  3. explicit same-document navigation within about:srcdoc. (#fragment)
  4. history same-document navigation within about:srcdoc (#fragment)

I mentioned the bfcache, because this comment said some about:srcdoc navigations may work only because of the bfcache. I disagreed, they work all the time, independently of it.

About the bfcache, please note that we support only main frame's bfcache navigation. Iframe's bfcache navigation aren't supported. We always store the page as a whole (=main document + its descendants in iframes). about:srcdoc can only be loaded inside an iframe. As a result, they may enter the bfcache and be restored, because their parent enter and leave the bfcache, however those are main frame navigation. BFCache navigation are never from/toward about:srcdoc directly.

domfarolino commented 2 years ago

About the bfcache, please note that we support only main frame's bfcache navigation.

You are speaking about Chrome here right? I think per spec, a session history entry's Document can be populated even if it corresponds with a subframe SH entry, so it seems that the spec has the concept of subframe BFCache, right?

Do we agree that per spec, history navigations to about:srcdoc should only ever work when the about:srcdoc Document is stored in the bfcache (despite Chrome allowing this regardless of bfcache)? If that is true, then for Chrome specifically, history navigations to about:srcdoc should always fail if Chrome followed the spec, since subframe history navigations are never bfcache navigations, and non-bfcache navigations to about:srcdoc should always fail. Is my understanding right here?

ArthurSonzogni commented 2 years ago

(sorry for the delay, I missed it. Thanks for the ping!)

You are speaking about Chrome here right?

Yes Chrome. Firefox too. And probably Webkit since it shouldn't have diverged too much since the blink/webkit fork.

Do we agree that per spec [...] except bfcache [...] history navigations to about:srcdoc should always fail.

I have very limited knowledge of the current spec. However, @domenic probably have seen spec about bfcache or about:srcdoc.

Chrome and Firefox allow history navigations to about:srcdoc. Please check this demo:

https://user-images.githubusercontent.com/4759106/144468799-8f766548-9c2f-4f19-887e-48c798479748.mp4

https://user-images.githubusercontent.com/4759106/144468855-7d253579-3d9e-49a1-974e-bc7a35876284.mp4

I don't know the spec, but allowing history navigation toward about:srcdoc seems to be the "defacto" standard adopted by every web browsers.

Then you are free to decide what to do with this information ;-) That's the best I can provide here.