[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 #1 from Brady Eidson <beidson at apple.com> ---
(In reply to comment #0)

> I was asked on twitter by @beidson, how 3 updates per second is not enough;
> my use case is updating scroll state at 60fps, 

Here's our thinking on this:
The use case for replaceState is to make sure that the current history item has the most recent state possible before the current history item changes.

The current history item really only needs to be updated exactly once - Right before the current history item moves to a new history item.

What is the difference between "updating the current history item 60 times during a 1 second scroll operation" versus "updating the current history item once at the end of a 1 second scroll operation"?

If the user is scrolling at 60fps for 1 second, for example, there's no need to update the state of the current history item 60 times. Only once at the end of the scrolling... or even better, only once right before the user "navigates"

In theory, I can't actually think of a reason you'd ever actually have to call "replaceState" other than "right before you ever call pushState, or once inside of your pagehide handler"

> but this example of a chat app:
> http://bl.ocks.org/jameskeane/raw/e0b145e6287b3f12f5e47e6b1d313308/
> also fails and is less easily coalesced.

Again, I'm confused why this is true - replaceState literally only needs to be called once before pushState, or once during pagehide.

I don't see what makes this chat app any different.

> I can find no reasonable justification for diverging from the spec
> (https://html.spec.whatwg.org/multipage/browsers.html#the-history-interface).

WebKit's current behavior is definitely inline with the HTML spec.

The WebApp section of the spec gives browsers leeway to prevent abuse of system resources by throwing the QuotaExceededError exception, which is precisely what we're doing here.
(https://html.spec.whatwg.org/multipage/webappapis.html#killing-scripts)

Also, the the History spec is clear about the flexibility user agents can take with regard to the state APIs in section 7.7.4. (https://html.spec.whatwg.org/multipage/browsers.html#history-notes)

While that section specifically calls out pushState, I assure you the intention was to call out replaceState also. I know this because I was directly involved in that conversation years ago when the APIs were new.

I've filed https://github.com/whatwg/html/issues/982 to update this.

-- 
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/20160402/1a60407a/attachment.html>