Implement the sandboxing for document.
Execute the Initialize document’s Feature Policy algorithm on - document.
Add document to browsingContext's session history.
Document created by these steps must have its URL set to:
- Initializing a new Document object: when a
- Document is created as part of the above steps, the user agent will be required to
- additionally run the following algorithm after creating the new object:
If browsingContext's only entry in its session history is the
- about:blank Document that was added when browsingContext
- was created, and navigation is occurring
- with replacement enabled, and that Document has the same
- origin as the new Document, then do nothing.
Otherwise:
- -Let realm execution context be the result of creating a new JavaScript - realm with the following customizations:
- -For the global object, create a new Window object.
For the global this binding, use browsingContext's
- WindowProxy object.
Set up a window environment settings object with realm execution - context and reservedEnvironment, if present.
Set the Document's HTTPS
- state to the HTTPS state of
- response.
Set the Document's referrer
- policy to the result of parsing the
- `Referrer-Policy` header of response.
Run the Initialize a Document's CSP list
- algorithm with the Document object, response, and
- request, as parameters.
If request is non-null, then set the document's referrer to the - serialization of request's referrer, if request's referrer is a URL record, and the empty - string otherwise.
- -Per the WHATWG Fetch standard a request's referrer will be either a URL record or
- "no-referrer" at this point.
Implement the sandboxing for the Document.
Execute the Initialize document’s Feature Policy from response
- algorithm on the Document object and the response used to generate the document.
The Initialize document’s Feature Policy from response algorithm
- makes use of the Document's origin. If document.domain has been used for the browsing
- context container's node document, then its origin cannot be
- same origin-domain with document's origin, because these
- steps run when document is initialized, so it cannot itself yet have used document.domain. Note that this means that Feature Policy
- checks are less permissive compared to doing a same origin check instead.
In this example, the child document is not allowed to use PaymentRequest,
- despite being same origin-domain at the time the child document tries to use
- it. At the time the child document is initialized, only the parent document has set document.domain, and the child document has not.
<!-- https://foo.example.com/a.html -->
-<!doctype html>
-<script>
- document.domain = 'example.com';
-</script>
-<iframe src=b.html></iframe><!-- https://bar.example.com/b.html -->
-<!doctype html>
-<script>
- document.domain = 'example.com'; // This happens after the document is initialized
- new PaymentRequest(…); // Not allowed to use
-</script>In this example, the child document is allowed to use
- PaymentRequest, despite not being same origin-domain at the time
- the child document tries to use it. At the time the child document is initialized, none of
- the documents have set document.domain yet so
- same origin-domain falls back to a normal same origin check.
<!-- https://example.com/a.html -->
-<!doctype html>
-<iframe src=b.html></iframe>
-<!-- The child document is now initialized, before the script below is run. -->
-<script>
- document.domain = 'example.com';
-</script><!-- https://example.com/b.html -->
-<!doctype html>
-<script>
- new PaymentRequest(…); // Allowed to use
-</script>If response has a `Refresh` header, then:
Let value be the isomorphic decoding - of the value of the header.
Run the shared declarative refresh steps with the Document
- and value.
Non-document content: If, given type, the new
@@ -82973,6 +82826,159 @@ interface Location { // but see also initialize the
+ Document object, given a Document object document, null
+ or a request request, a response response, a browsing context browsingContext, and an optional
+ environment reservedEnvironment:
The sections below do not yet explicitly call this algorithm, + passing along the appropriate arguments. Instead, they just reference it by name. We hope to fix + this, but in the meantime, understand that the arguments should be threaded through from + process a navigate response to here.
+ +If browsingContext's only entry in its session history is the
+ about:blank Document that was added when browsingContext was
+ created, and navigation is occurring with
+ replacement enabled, and that Document has the same origin
+ as document, then do nothing.
Otherwise:
+ +Let realm execution context be the result of creating a new JavaScript + realm with the following customizations:
+ +For the global object, create a new Window object.
For the global this binding, use browsingContext's
+ WindowProxy object.
Set up a window environment settings object with realm execution + context and reservedEnvironment, if present.
If request is non-null, then set + document's URL to request's + current URL.
Otherwise, set document's URL to + response's URL.
Set document's HTTPS state + to the HTTPS state of + response.
Set document's referrer
+ policy to the result of parsing the
+ `Referrer-Policy` header of response.
Initialize a Document's CSP list given
+ document, response, and request.
If request is non-null, then set document's referrer to the serialization of request's referrer, if request's referrer is a URL record, and the empty + string otherwise.
+ +Per Fetch a request's referrer will be either a URL record or
+ "no-referrer" at this point.
Implement the sandboxing for document.
Initialize a document's feature policy from a response given + document and response.
+ +The initialize a document's feature policy from a response algorithm makes use
+ of document's origin. If document.domain has been used for the browsing
+ context container's node document, then its origin cannot be
+ same origin-domain with document's origin, because these
+ steps run when document is initialized, so it cannot itself yet have used document.domain. Note that this means that Feature Policy
+ checks are less permissive compared to doing a same origin check instead.
See below for some examples of this in action.
+If response has a `Refresh` header, then:
Let value be the isomorphic decoding + of the value of the header.
Run the shared declarative refresh steps with document and + value.
We do
+ not currently have a spec for how to handle multiple `Refresh` headers.
In this example, the child document is not allowed to use PaymentRequest,
+ despite being same origin-domain at the time the child document tries to use
+ it. At the time the child document is initialized, only the parent document has set document.domain, and the child document has not.
<!-- https://foo.example.com/a.html -->
+<!doctype html>
+<script>
+document.domain = 'example.com';
+</script>
+<iframe src=b.html></iframe><!-- https://bar.example.com/b.html -->
+<!doctype html>
+<script>
+document.domain = 'example.com'; // This happens after the document is initialized
+new PaymentRequest(…); // Not allowed to use
+</script>In this example, the child document is allowed to use
+ PaymentRequest, despite not being same origin-domain at the time
+ the child document tries to use it. At the time the child document is initialized, none of
+ the documents have set document.domain yet so
+ same origin-domain falls back to a normal same origin check.
<!-- https://example.com/a.html -->
+<!doctype html>
+<iframe src=b.html></iframe>
+<!-- The child document is now initialized, before the script below is run. -->
+<script>
+document.domain = 'example.com';
+</script><!-- https://example.com/b.html -->
+<!doctype html>
+<script>
+new PaymentRequest(…); // Allowed to use
+</script>Some of the sections below, to which the above algorithm defers in certain cases, require the
user agent to update the session history with the new page. When a user agent is
required to do this, it must queue a task (associated with the Document