Re: [whatwg] Order of popstate event and scroll restoration - interop issue

On 08/11/2015 05:08 PM, Majid Valipour wrote:
> According to HTML5 spec persisted user state (scroll, scale, form values,
> etc)
> should be restored before dispatching popstate event. (See steps 9 and 14 in
> history traversal algorithm[1]).
>
> Gecko and IE follow the spec order for scroll position but in Blink and
> WebKit
> the order is reversed specifically:
> 1. 'popstate' event dispatched
> 2.  scroll position restored  (only if user has not scrolled)
> 3. 'hashchanged' event dispatched (only if hash changed)
>
> We have learned that single-page applications depend on this reverse order
> to
> implement a simple workaround to override automatic scroll position
> restoration with their own application specific one. The workaround is to
> record the scroll position on (1), and restore it on (3). In fact, a recent
> change in the Blink's order [2] broke major sites that depended on this
> reverse order and we had to revert it.
>
> At the same time, this means that the scroll restoration for any sites that
> uses this workaround does not work well in Firefox and IE. I have heard
> examples of this from Mozilla engineers.

Indeed. There is a patch ready to implement popstate, scroll restoration, hashchanged
behavior in Gecko. That fixes Github back-forward for example.
But the patch didn't land because of being against the spec.

>
> There are two options to get an interop solution:
> Option 1. Change the spec to reverse order, making the workaround supported
> officially.
> Does anybody know if there was any specific reasons behind the current
> order?

If we do this, I think popstate event should also become cancelable, so that web page could easily
prevent  scrolling (in that case there wouldn't be need to play with scrollRestoration always)

>
> Option 2. Keep the spec order, and have Blink and Webkit match it.
> This depends on having a reliable methods for controlling scroll restoration
> so that current workaround users can switch to it. Fortunately
> history.scrollRestoration [3, 4] provides exactly this alternative and we
> are
> working toward shipping it in blink in the next release [5].
>


> I prefer option 2 mainly because the current order has the advantage that
> when
> 'popstate' is dispatched the application is guaranteed that the user-agent
> is
> done with restoring the state, and current values are reliable. Furthermore,
> the workaround has multiple other limitations:
>      - scroll position needs to be restored synchronously otherwise a jump is
>        visible
>      - requires apps to create artificial hashchange events
>
> Have I missed any other solution?
>
> Majid
>
> [1]
> https://html.spec.whatwg.org/multipage/browsers.html#traverse-the-history
> [2] https://crbug.com/474579
> [3]
> https://lists.w3.org/Archives/Public/public-whatwg-archive/2015May/0063.html
> [4]
> https://html.spec.whatwg.org/multipage/browsers.html#traverse-the-history
> [5] https://crbug.com/444094
>

Received on Wednesday, 12 August 2015 07:32:33 UTC