[Webkit-unassigned] [Bug 156115] Remove arbitrary limit on pushState and replaceState

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=156115

--- Comment #5 from Brady Eidson <beidson at apple.com> ---
Re-ordering my reply a bit to make a better narrative:

(In reply to comment #4)
> (In reply to comment #3)
> 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.

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.

> 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.

We will definitely consider ignoring the call, but logging to the console anyways.

> Again, not knowing the specifics, how could 'replaceState' create an OOM
> situation? Is it not deallocating the previous state object?

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.

> > 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.

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160405/d5ff512f/attachment.html>