Skip to content

Commit

Permalink
Editorial: move navigation document initialization
Browse files Browse the repository at this point in the history 
Previously, it was indented into the middle of "process a navigate
response", which made that algorithm really hard to read. There was also
a standalone "set the Document's address" algorithm which was never
called, but said it must be performed at the appropriate time.

This moves the algorithm out to be a sibling of "process a navigate
response", with appropriate inputs, and includes the step to set the URL
directly in the algorithm.

Closes #3327.
  • Loading branch information
@domenic
domenic committed Feb 27, 2019
1 parent e13762f commit 91902bd
Showing 1 changed file with 157 additions and 151 deletions.
308 changes: 157 additions & 151 deletions source
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4074,8 +4074,8 @@ a.setAttribute('href', 'https://example.com/'); // change the content attribute
<li><dfn data-x="concept-container-policy" data-x-href="https://wicg.github.io/feature-policy/#container-policy">container policy</dfn></li>
<li><dfn data-x="concept-serialized-feature-policy" data-x-href="https://wicg.github.io/feature-policy/#serialized-feature-policy">serialized feature policy</dfn></li>
<li><dfn data-x="concept-default-allowlist" data-x-href="https://wicg.github.io/feature-policy/#default-allowlist">default allowlist</dfn></li>
<li>The <dfn data-x-href="https://wicg.github.io/feature-policy/#initialize-for-document">Initialize document’s feature policy</dfn> algorithm</li>
<li>The <dfn data-x-href="https://wicg.github.io/feature-policy/#initialize-from-response">Initialize document’s feature policy from response</dfn> algorithm</li>
<li>The <dfn data-x-href="https://wicg.github.io/feature-policy/#initialize-for-document">Initialize a document's feature policy</dfn> algorithm</li>
<li>The <dfn data-x-href="https://wicg.github.io/feature-policy/#initialize-from-response">Initialize a document's feature policy from a response</dfn> algorithm</li>
<li>The <dfn data-x="is-feature-enabled" data-x-href="https://wicg.github.io/feature-policy/#is-feature-enabled">Is feature enabled by policy for origin</dfn> algorithm</li>
<li>The <dfn data-x="process-feature-policy-attributes" data-x-href="https://wicg.github.io/feature-policy/#process-feature-policy-attributes">Process feature policy attributes</dfn> algorithm</li>
</ul>
Expand Down Expand Up @@ -77234,8 +77234,8 @@ dictionary <dfn>DragEventInit</dfn> : <span>MouseEventInit</span> {

<li><p><span>Implement the sandboxing</span> for <var>document</var>.</p></li>

<li><p>Execute the <span>Initialize document’s Feature Policy</span> algorithm on
<var>document</var>. <ref spec="FEATUREPOLICY"></p></li>
<li><p><span>Initialize a document's feature policy</span> given <var>document</var>. <ref
spec="FEATUREPOLICY"></p></li>

<li><p>Add <var>document</var> to <var>browsingContext</var>'s <span>session
history</span>.</p></li>
Expand Down Expand Up @@ -82677,153 +82677,6 @@ interface <dfn>Location</dfn> { // but see also <a href="#the-location-interface
<span>plugin</span> rendering directly in <var>browsingContext</var>, or a separate
application), or one for which the user agent has dedicated processing rules, or one for which
the user agent has a dedicated handler.</p>

<p><dfn data-x="set the document's address">Setting the document's address</dfn>: Any
<code>Document</code> created by these steps must have its <span
data-x="concept-document-url">URL</span> set to:</p>
<dl class="switch">
<dt>If <var>request</var> is non-null,</dt>
<dd><var>request</var>'s <span data-x="concept-request-current-url">current URL</span></dd>
<dt>Otherwise (<var>request</var> is null),</dt>
<dd><var>response</var>'s <span data-x="concept-response-url">URL</span></dd>
</dl>

<p><!--en-GB--><dfn id="initialise-the-document-object" data-x="initialize the Document object"
data-export="">Initializing a new <code>Document</code> object</dfn>: when a
<code>Document</code> 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:</p>

<ol>
<li><p>If <var>browsingContext</var>'s only entry in its <span>session history</span> is the
<code>about:blank</code> <code>Document</code> that was added when <var>browsingContext</var>
was <span data-x="creating a new browsing context">created</span>, and navigation is occurring
with <span>replacement enabled</span>, and that <code>Document</code> has the <span>same
origin</span> as the new <code>Document</code>, then do nothing.</p></li>

<li>
<p>Otherwise:</p>

<ol>
<li>
<p>Let <var>realm execution context</var> be the result of <span>creating a new JavaScript
realm</span> with the following customizations:</p>

<ul>
<li><p>For the global object, create a new <code>Window</code> object.</p></li>

<li><p>For the global <b>this</b> binding, use <var>browsingContext</var>'s
<code>WindowProxy</code> object.</p></li>
</ul>
</li>

<li><p><span>Set up a window environment settings object</span> with <var>realm execution
context</var> and <var>reservedEnvironment</var>, if present.</p></li>
</ol>
</li>

<li><p>Set the <code>Document</code>'s <span data-x="concept-document-https-state">HTTPS
state</span> to the <span data-x="concept-response-https-state">HTTPS state</span> of
<var>response</var>.</p></li>

<li><p>Set the <code>Document</code>'s <span data-x="concept-document-referrer-policy">referrer
policy</span> to the result of <span data-x="parse-referrer-policy-header">parsing the
`<code>Referrer-Policy</code>` header</span> of <var>response</var>. <ref
spec="REFERRERPOLICY"></p></li>

<li><p>Run the <span>Initialize a <code data-x="">Document</code>'s CSP list</span>
algorithm with the <code>Document</code> object, <var>response</var>, and
<var>request</var>, as parameters. <ref spec="CSP"></p>

<li>
<p>If <var>request</var> is non-null, then set <span>the document's referrer</span> to the
<span data-x="concept-url-serializer">serialization</span> of <var>request</var>'s <span
data-x="concept-request-referrer">referrer</span>, if <var>request</var>'s <span
data-x="concept-request-referrer">referrer</span> is a <span>URL record</span>, and the empty
string otherwise.</p>

<p class="note">Per the WHATWG Fetch standard a <span
data-x="concept-request">request</span>'s <span
data-x="concept-request-referrer">referrer</span> will be either a <span>URL record</span> or
"<code data-x="">no-referrer</code>" at this point.</p>
</li>

<li><p><span>Implement the sandboxing</span> for the <code>Document</code>.</p></li>

<li>
<p>Execute the <span>Initialize document’s Feature Policy from response</span>
algorithm on the <code>Document</code> object and the <span
data-x="concept-response">response</span> used to generate the document. <ref
spec="FEATUREPOLICY"></p>

<p class="note">The <span>Initialize document’s Feature Policy from response</span> algorithm
makes use of the <code>Document</code>'s <span>origin</span>. If <code
data-x="dom-document-domain">document.domain</code> has been used for the <span>browsing
context container</span>'s <span>node document</span>, then its <span>origin</span> cannot be
<span>same origin-domain</span> with <var>document</var>'s <span>origin</span>, because these
steps run when <var>document</var> is initialized, so it cannot itself yet have used <code
data-x="dom-document-domain">document.domain</code>. Note that this means that Feature Policy
checks are less permissive compared to doing a <span>same origin</span> check instead.</p>

<div class="example">
<p>In this example, the child document is not allowed to use <code>PaymentRequest</code>,
despite being <span>same origin-domain</span> at the time the child document tries to use
it. At the time the child document is initialized, only the parent document has set <code
data-x="dom-document-domain">document.domain</code>, and the child document has not.</p>

<pre><code class="html" data-x="">&lt;!-- https://foo.example.com/a.html -->
&lt;!doctype html>
&lt;script>
document.domain = 'example.com';
&lt;/script>
&lt;iframe src=b.html>&lt;/iframe></code></pre>

<pre><code class="html" data-x="">&lt;!-- https://bar.example.com/b.html -->
&lt;!doctype html>
&lt;script>
document.domain = 'example.com'; // This happens after the document is initialized
new PaymentRequest(&hellip;); // Not allowed to use
&lt;/script></code></pre>
</div>

<div class="example">
<p>In this example, the child document <em>is</em> allowed to use
<code>PaymentRequest</code>, despite not being <span>same origin-domain</span> at the time
the child document tries to use it. At the time the child document is initialized, none of
the documents have set <code data-x="dom-document-domain">document.domain</code> yet so
<span>same origin-domain</span> falls back to a normal <span>same origin</span> check.</p>

<pre><code class="html" data-x="">&lt;!-- https://example.com/a.html -->
&lt;!doctype html>
&lt;iframe src=b.html>&lt;/iframe>
&lt;!-- The child document is now initialized, before the script below is run. -->
&lt;script>
document.domain = 'example.com';
&lt;/script></code></pre>

<pre><code class="html" data-x="">&lt;!-- https://example.com/b.html -->
&lt;!doctype html>
&lt;script>
new PaymentRequest(&hellip;); // Allowed to use
&lt;/script></code></pre>
</div>
</li>

<li>
<p>If <var>response</var> has a `<code data-x="http-refresh">Refresh</code>` header, then:</p>

<ol>
<li><p class="&#x0058;&#x0058;&#x0058;"><a
href="https://github.com/whatwg/html/issues/2900">Multiple `<code
data-x="http-refresh">Refresh</code>` headers</a>.</p></li>

<li><p>Let <var>value</var> be the <span data-x="isomorphic decode">isomorphic decoding</span>
of the value of the header.</p></li>

<li><p>Run the <span>shared declarative refresh steps</span> with the <code>Document</code>
and <var>value</var>.</p></li>
</ol>
</li>
</ol>
</li>

<li id="navigate-non-Document"><p><i>Non-document content</i>: If, given <var>type</var>, the new
Expand Down Expand Up @@ -82973,6 +82826,159 @@ interface <dfn>Location</dfn> { // but see also <a href="#the-location-interface

<hr>

<p>Some of the sections below, to which the above algorithm defers in certain cases, use the
following steps to <!--en-GB--><dfn id="initialise-the-document-object">initialize the
<code>Document</code> object</dfn>, given a <code>Document</code> object <var>document</var>, null
or a <span data-x="concept-request">request</span> <var>request</var>, a <span
data-x="concept-response">response</span> <var>response</var>, a <span data-x="browsing
context">browsing context</span> <var>browsingContext</var>, and an optional
<span>environment</span> <var>reservedEnvironment</var>:</p>

<p class="&#x0058;&#x0058;&#x0058;">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
<span>process a navigate response</span> to here.</p>

<ol>
<li><p>If <var>browsingContext</var>'s only entry in its <span>session history</span> is the
<code>about:blank</code> <code>Document</code> that was added when <var>browsingContext</var> was
<span data-x="creating a new browsing context">created</span>, and navigation is occurring with
<span>replacement enabled</span>, and that <code>Document</code> has the <span>same origin</span>
as <var>document</var>, then do nothing.</p></li>

<li>
<p>Otherwise:</p>

<ol>
<li>
<p>Let <var>realm execution context</var> be the result of <span>creating a new JavaScript
realm</span> with the following customizations:</p>

<ul>
<li><p>For the global object, create a new <code>Window</code> object.</p></li>

<li><p>For the global <b>this</b> binding, use <var>browsingContext</var>'s
<code>WindowProxy</code> object.</p></li>
</ul>
</li>

<li><p><span>Set up a window environment settings object</span> with <var>realm execution
context</var> and <var>reservedEnvironment</var>, if present.</p></li>
</ol>
</li>

<li id="set-the-document's-address"><p>If <var>request</var> is non-null, then set
<var>document</var>'s <span data-x="concept-document-url">URL</span> to <var>request</var>'s
<span data-x="concept-request-current-url">current URL</span>.</p></li>

<li><p>Otherwise, set <var>document</var>'s <span data-x="concept-document-url">URL</span> to
<var>response</var>'s <span data-x="concept-response-url">URL</span>.</p></li>

<li><p>Set <var>document</var>'s <span data-x="concept-document-https-state">HTTPS state</span>
to the <span data-x="concept-response-https-state">HTTPS state</span> of
<var>response</var>.</p></li>

<li><p>Set <var>document</var>'s <span data-x="concept-document-referrer-policy">referrer
policy</span> to the result of <span data-x="parse-referrer-policy-header">parsing the
`<code>Referrer-Policy</code>` header</span> of <var>response</var>. <ref
spec="REFERRERPOLICY"></p></li>

<li><p><span>Initialize a <code data-x="">Document</code>'s CSP list</span> given
<var>document</var>, <var>response</var>, and <var>request</var>. <ref spec="CSP"></p>

<li>
<p>If <var>request</var> is non-null, then set <var>document</var>'s <span data-x="the
document's referrer">referrer</span> to the <span
data-x="concept-url-serializer">serialization</span> of <var>request</var>'s <span
data-x="concept-request-referrer">referrer</span>, if <var>request</var>'s <span
data-x="concept-request-referrer">referrer</span> is a <span>URL record</span>, and the empty
string otherwise.</p>

<p class="note">Per <cite>Fetch</cite> a <span data-x="concept-request">request</span>'s <span
data-x="concept-request-referrer">referrer</span> will be either a <span>URL record</span> or
"<code data-x="">no-referrer</code>" at this point.</p>
</li>

<li><p><span>Implement the sandboxing</span> for <var>document</var>.</p></li>

<li>
<p><span>Initialize a document's feature policy from a response</span> given
<var>document</var> and <var>response</var>. <ref spec="FEATUREPOLICY"></p>

<div class="note">
<p>The <span>initialize a document's feature policy from a response</span> algorithm makes use
of <var>document</var>'s <span>origin</span>. If <code
data-x="dom-document-domain">document.domain</code> has been used for the <span>browsing
context container</span>'s <span>node document</span>, then its <span>origin</span> cannot be
<span>same origin-domain</span> with <var>document</var>'s <span>origin</span>, because these
steps run when <var>document</var> is initialized, so it cannot itself yet have used <code
data-x="dom-document-domain">document.domain</code>. Note that this means that Feature Policy
checks are less permissive compared to doing a <span>same origin</span> check instead.</p>

<p>See below for some examples of this in action.</p>
</div>
</li>

<li>
<p>If <var>response</var> has a `<code data-x="http-refresh">Refresh</code>` header, then:</p>

<ol>
<li><p>Let <var>value</var> be the <span data-x="isomorphic decode">isomorphic decoding</span>
of the value of the header.</p></li>

<li><p>Run the <span>shared declarative refresh steps</span> with <var>document</var> and
<var>value</var>.</p></li>
</ol>

<p class="&#x0058;&#x0058;&#x0058;"><a href="https://github.com/whatwg/html/issues/2900">We do
not currently have a spec for how to handle multiple `<code
data-x="http-refresh">Refresh</code>` headers</a>.</p>
</li>
</ol>

<div class="example">
<p>In this example, the child document is not allowed to use <code>PaymentRequest</code>,
despite being <span>same origin-domain</span> at the time the child document tries to use
it. At the time the child document is initialized, only the parent document has set <code
data-x="dom-document-domain">document.domain</code>, and the child document has not.</p>

<pre><code class="html" data-x="">&lt;!-- https://foo.example.com/a.html -->
&lt;!doctype html>
&lt;script>
document.domain = 'example.com';
&lt;/script>
&lt;iframe src=b.html>&lt;/iframe></code></pre>

<pre><code class="html" data-x="">&lt;!-- https://bar.example.com/b.html -->
&lt;!doctype html>
&lt;script>
document.domain = 'example.com'; // This happens after the document is initialized
new PaymentRequest(&hellip;); // Not allowed to use
&lt;/script></code></pre>
</div>

<div class="example">
<p>In this example, the child document <em>is</em> allowed to use
<code>PaymentRequest</code>, despite not being <span>same origin-domain</span> at the time
the child document tries to use it. At the time the child document is initialized, none of
the documents have set <code data-x="dom-document-domain">document.domain</code> yet so
<span>same origin-domain</span> falls back to a normal <span>same origin</span> check.</p>

<pre><code class="html" data-x="">&lt;!-- https://example.com/a.html -->
&lt;!doctype html>
&lt;iframe src=b.html>&lt;/iframe>
&lt;!-- The child document is now initialized, before the script below is run. -->
&lt;script>
document.domain = 'example.com';
&lt;/script></code></pre>

<pre><code class="html" data-x="">&lt;!-- https://example.com/b.html -->
&lt;!doctype html>
&lt;script>
new PaymentRequest(&hellip;); // Allowed to use
&lt;/script></code></pre>
</div>

<p>Some of the sections below, to which the above algorithm defers in certain cases, require the
user agent to <dfn>update the session history with the new page</dfn>. When a user agent is
required to do this, it must <span>queue a task</span> (associated with the <code>Document</code>
Expand Down

0 comments on commit 91902bd

Please sign in to comment.