<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Remove arbitrary limit on pushState and replaceState"
href="https://bugs.webkit.org/show_bug.cgi?id=156115#c2">Comment # 2</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Remove arbitrary limit on pushState and replaceState"
href="https://bugs.webkit.org/show_bug.cgi?id=156115">bug 156115</a>
from <span class="vcard"><a class="email" href="mailto:james.keane@flipp.com" title="James Keane <james.keane@flipp.com>"> <span class="fn">James Keane</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=156115#c1">comment #1</a>)
<span class="quote">> The current history item really only needs to be updated exactly once - Right before the current history item moves to a new history item.</span >
While that may be the case, it goes against the spirit of the API i.e. of allowing the state or URL to be replaced when convenient, otherwise why provide a method at all?
What you are describing may in fact be a better way to fix this issue in WebKit itself while hiding platform specific memory limitations.
Not being familiar with WebKit myself, how is this:
<span class="quote">> for(var i = 0; i < 1000; i++) document.location.hash = String(i);</span >
limited, protected, or otherwise made 'safe' in a similar manner?
As for Section 7.7.4 it states (emphasis mine):
<span class="quote">> In addition, a user agent could *ignore calls* to pushState() 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.</span >
Which is *not* WebKit's behaviour in this case, as it is not merely ignoring those calls.
Also in Section 7.7.4, the paragraph you reference, labelled 'Security', is discussing history hijacking, in which a nefarious page prevents a user from using the back button to leave a page; which does not appear relevant to this discussion.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>