<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#c3">Comment # 3</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:beidson@apple.com" title="Brady Eidson <beidson@apple.com>"> <span class="fn">Brady Eidson</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=156115#c2">comment #2</a>)
<span class="quote">> (In reply to <a href="show_bug.cgi?id=156115#c1">comment #1</a>)
>
> > The current history item really only needs to be updated exactly once - Right before the current history item moves to a new history item.
>
> 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?</span >
I'm suggesting that replaceState only needs to be called once once.
You're suggesting it's necessary to call it 60 fps.
"When convenient" is somewhere in between and would likely be allowed by the current policy.
<span class="quote">> What you are describing may in fact be a better way to fix this issue in
> WebKit itself while hiding platform specific memory limitations.</span >
WebKit cannot possibly know when the page is about to "fake navigate" via a pushState. Analyzing a program to try to figure that out is subject to the halting problem. Only the web author can know this.
<span class="quote">> Not being familiar with WebKit myself, how is this:
> > for(var i = 0; i < 1000; i++) document.location.hash = String(i);
> limited, protected, or otherwise made 'safe' in a similar manner?</span >
A browser engine can't stop JS programmers from doing *all* unreasonably inefficient things.
It can step in to stop particularly nefarious ones, though.
<span class="quote">>
> As for Section 7.7.4 it states (emphasis mine):
> > 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.
>
> Which is *not* WebKit's behaviour in this case, as it is not merely ignoring
> those calls.</span >
So you're suggesting it's the exception being thrown that is the problem, and not the policy itself?
If so, we should probably close this bug and restart that conversation with a clean slate, because that's a different conversation.
<span class="quote">> 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.</span >
Apologies for suggesting that I was only referencing that paragraph - I'm references the entire section.
If we're citing sections of the spec with emphasis, though, I'll emphasize 2.2.1 (<a href="https://html.spec.whatwg.org/multipage/infrastructure.html#conformance-classes">https://html.spec.whatwg.org/multipage/infrastructure.html#conformance-classes</a>):
<span class="quote">> User agents *may impose implementation-specific limits on otherwise unconstrained inputs*, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations.</span >
And 8.1.3.5 (<a href="https://html.spec.whatwg.org/multipage/webappapis.html#killing-scripts">https://html.spec.whatwg.org/multipage/webappapis.html#killing-scripts</a>):
<span class="quote">> ...it's sometimes necessary to abort a running script.
> ...
> User agents may impose resource limitations on scripts, for example CPU quotas, memory limits, total execution time limits, or bandwidth limitations. When a script exceeds a limit, the user agent may either throw a QuotaExceededError exception</span >
QuotaExceededError when a script exceeds a limit is what we're doing.
Again, if the objection is to the exception as opposed to the limit itself, we should discuss in a clean slate bug.</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>