<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#c5">Comment # 5</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>Re-ordering my reply a bit to make a better narrative:
(In reply to <a href="show_bug.cgi?id=156115#c4">comment #4</a>)
<span class="quote">> (In reply to <a href="show_bug.cgi?id=156115#c3">comment #3</a>)
> Brady, I would also like to personally apologize, if my initial tweets
> offended you; I was frustrated at what, at the time, I believed was a spec
> violating change causing hundreds of thousands of users to see a completely
> broken site.</span >
Apology noted, but not necessary; I wasn't offended, I just wanted to probe the use case and get to the bottom of the problem.
<span class="quote">> I will leave it to you to decide whether throwing a QuotaExceededError, or
> as the spec _suggests_ ignoring calls is the preferred behaviour; my opinion
> is the latter.</span >
We will definitely consider ignoring the call, but logging to the console anyways.
<span class="quote">> Again, not knowing the specifics, how could 'replaceState' create an OOM
> situation? Is it not deallocating the previous state object?</span >
Yes, replaceState deallocates the previous state objects, but this policy is not about OOM.
Calling replaceState at a high frequency, even with tiny payloads, does a surprising amount of work. It burns through a surprising amount of CPU, which means a surprising amount of battery.
And if the frequency is high enough it actually quickly turns into a DOS attack. Not only on the current web page but on the entire browser, as the browser itself is necessarily involved with session history management.
<span class="quote">> > WebKit cannot possibly know when the page is about to "fake navigate" via a pushState.
> It can, and it is definitely *not* a halting problem; it knows when the page
> is about to fake navigate, as it knows when pushState is called.</span >
That's absolutely true.
Let me rephrase: WebKit can't do analysis about each replaceState to see if it is the "last replaceState that is needed before a pushState"
I believe what you're considering an appropriate fix in WebKit would be remember the most recent "replaceState" in a lightweight manner, then only do the heavyweight work when pushState is called or a navigation happens.
We considered that at first, but there are significant problems with it, both technical and architectural.</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>