Skip to content

Make it explicit that user agents can ignore replaceState/pushState #999

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
domenic merged 2 commits into from
Apr 6, 2016
Merged

Make it explicit that user agents can ignore replaceState/pushState #999

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c937a9f
Move "Implementation notes for session history" before Location
domenic Apr 5, 2016
38139b4
Make it explicit that user agents can ignore replaceState/pushState
domenic Apr 5, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
77 changes: 41 additions & 36 deletions source
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -79430,6 +79430,10 @@ interface <dfn>History</dfn> {
<li><p>If this <code>History</code> object is associated with a <code>Document</code> that is
not <span>fully active</span>, throw a <code>SecurityError</code> exception.</p></li>

<li><p>Optionally, abort these steps. (For example, the user agent might disallow calls to these
methods that are invoked on a timer, or from event listeners that are not triggered in response
to a clear user action, or that are invoked in rapid succession.)</p></li>

<li><p>Let <var>targetRealm</var> be this <code>History</code> object's <span>relevant settings
object</span>'s <span data-x="environment settings object's realm">Realm</span>.</p></li>

Expand Down Expand Up @@ -79670,6 +79674,43 @@ State: &lt;OUTPUT NAME=I>1&lt;/OUTPUT> &lt;INPUT VALUE="Increment" TYPE=BUTTON O
</div>


<div w-nodev>

<h4 id="history-notes">Implementation notes for session history</h4>
<!-- don't change the ID without updating multiple internal links -->

<!-- NON-NORMATIVE SECTION -->

<p>The <code>History</code> interface is not meant to place restrictions on how implementations
represent the session history to the user.</p>

<p>For example, session history could be implemented in a tree-like manner, with each page having
multiple "forward" pages. This specification doesn't define how the linear list of pages in the
<code data-x="dom-history">history</code> object are derived from the actual session history as
seen from the user's perspective.</p>

<p>Similarly, a page containing two <code>iframe</code>s has a <code
data-x="dom-history">history</code> object distinct from the <code>iframe</code>s' <code
data-x="dom-history">history</code> objects, despite the fact that typical Web browsers present the
user with just one "Back" button, with a session history that interleaves the navigation of the
two inner frames and the outer page.</p>

Copy link
Member

@annevk annevk Apr 6, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this appears in a non-normative section, we cannot use should.

<!--ADD-TOPIC:Security-->
<p><strong>Security</strong>: It is suggested that to avoid letting a page "hijack" the history
navigation facilities of a UA by abusing <code data-x="dom-history-pushState">pushState()</code>,
the UA provide the user with a way to jump back to the previous page (rather than just going back
to the previous state). For example, the back button could have a drop down showing just the pages
in the session history, and not showing any of the states. Similarly, an aural browser could have
two "back" commands, one that goes back to the previous state, and one that jumps straight back to
the previous page.</p>

<p>For both <code data-x="dom-history-pushState">pushState()</code> and <code
data-x="dom-history-replaceState">replaceState()</code>, user agents are encouraged to prevent
abuse of these APIs via too-frequent calls or over-large state objects. As detailed above, the
algorithm explicitly allows user agents to ignore any such calls when appropriate.</p>
<!--REMOVE-TOPIC:Security-->

</div>


<h4>The <code>Location</code> interface</h4>
Expand Down Expand Up @@ -80509,42 +80550,6 @@ State: &lt;OUTPUT NAME=I>1&lt;/OUTPUT> &lt;INPUT VALUE="Increment" TYPE=BUTTON O
<li><p>Return ! <span>CrossOriginOwnPropertyKeys</span>(<b>this</b>).</p></li>
</ol>



<h4 id="history-notes">Implementation notes for session history</h4>
<!-- don't change the ID without updating multiple internal links -->

<!-- NON-NORMATIVE SECTION -->

<p>The <code>History</code> interface is not meant to place restrictions on how implementations
represent the session history to the user.</p>

<p>For example, session history could be implemented in a tree-like manner, with each page having
multiple "forward" pages. This specification doesn't define how the linear list of pages in the
<code data-x="dom-history">history</code> object are derived from the actual session history as
seen from the user's perspective.</p>

<p>Similarly, a page containing two <code>iframe</code>s has a <code
data-x="dom-history">history</code> object distinct from the <code>iframe</code>s' <code
data-x="dom-history">history</code> objects, despite the fact that typical Web browsers present the
user with just one "Back" button, with a session history that interleaves the navigation of the
two inner frames and the outer page.</p>

<!--ADD-TOPIC:Security-->
<p><strong>Security</strong>: It is suggested that to avoid letting a page "hijack" the history
navigation facilities of a UA by abusing <code data-x="dom-history-pushState">pushState()</code>,
the UA provide the user with a way to jump back to the previous page (rather than just going back
to the previous state). For example, the back button could have a drop down showing just the pages
in the session history, and not showing any of the states. Similarly, an aural browser could have
two "back" commands, one that goes back to the previous state, and one that jumps straight back to
the previous page.</p>

<p>In addition, a user agent could ignore calls to <code
data-x="dom-history-pushState">pushState()</code> that are invoked on a timer, or from event
listeners that are not triggered in response to a clear user action, or that are invoked in rapid
succession.</p>
<!--REMOVE-TOPIC:Security-->

</div>


Expand Down