Repository navigation
Snapshot fallback base URL for about:-schemed Documents - #9464
Conversation
domenic
left a comment
There was a problem hiding this comment.
I suspect http://localhost:8080/#the-javascript:-url-special-case also needs to copy over the about base URL, since that case creates a new document state that replaces the old one, but keeps the URL (which might be something like about:srcdoc or about:blank).
Can you be sure to write tests for that case?
Yeah I think you're right. I made two changes: copied the document state member over manually in the algorithm you linked to, and assigned the navigation params's about base URL to the target navigable's active document's about base URL, since this happens in a separate algorithm. I think that should do the trick. Thanks for the review. I'm going to make sure tests get written for:
|
|
I'm OOO until Tuesday, but I think James already wrote tests for #3989. |
|
Are there document.open() + about:srcdoc scenarios we need to test in addition to document-base-url-changes-about-srcdoc-2.https.html ? |
|
Nope I don't think so. |
domenic
left a comment
There was a problem hiding this comment.
LGTM with one question. Also note my nit fixes.
|
Thanks. OK I think this should be good to go, depending on what our policy for writing WPTs for |
|
Tests for object and embed would be appreciated but definitely not blocking. There are so many interop and spec problems with them, anything in that area is just best-effort. |
This PR gives an "about base URL" member to:
The intention is to capture a document's creator's base URL in https://html.spec.whatwg.org/C#creating-a-new-browsing-context and preserve it to (1) the newly created document itself, and (2) the newly-created document state in both:
For the navigation case, we capture the initiator's base URL in #navigate as initiatorBaseURLSnapshot alongside initiatorOriginSnapshot. We preserve this to the document state created in #navigate when navigating to about:-scheme URLs, alongside the document state's origin. It is later used in #create-navigation-params-by-fetching and the
about:srcdoccase for population of the navigation params's about base URL, so it can be transferred to the actual document in https://html.spec.whatwg.org/C#initialise-the-document-object.Finally, we remove the concept of a browsing context's https://html.spec.whatwg.org/C#creator-base-url algorithm, and in https://html.spec.whatwg.org/C#fallback-base-url we only reference the new
concept-document-about-base-URLmember which is a snapshot of the creator/initiator base URL.There are a few instances of manually-constructed navigation params outside of the normal flow:
The response-is-null case: https://html.spec.whatwg.org/C#beginning-navigation:navigation-paramsThejavascript:URL special case: https://html.spec.whatwg.org/C#the-javascript:-url-special-case:navigation-paramsAs of now this PR passes in null for the navigation params's about base URL in these (not stricken-through) cases above, but I'm not sure if that is correct. I'm looking into it and it is perhaps the one thing blocking this PR at this case.
Closes #421. Closes #2883. Closes #3989.
At least two implementers are interested (and none opposed):
Tests are written and can be reviewed and commented upon at:
Implementation bugs are filed:
MDN issue is filed: …
(See WHATWG Working Mode: Changes for more details.)
/browsing-the-web.html ( diff )
/document-lifecycle.html ( diff )
/document-sequences.html ( diff )
/dom.html ( diff )
/urls-and-fetching.html ( diff )