Always fire popstate and restore persisted state sync

[domenic]

Closes #1792 by aligning with Gecko. The alternative model involved delaying popstate until after the load event, which is what Blink and WebKit do. But the Gecko model is simpler and has fewer edge cases around multiple state changes and such.

• At least two implementers are interested (and none opposed):
  • Gecko implements this
  • Blink is working on doing so: https://chromium-review.googlesource.com/c/chromium/src/+/3580022
• Tests are written and can be reviewed and commented upon at:
  • Make popstate always fire synchronously web-platform-tests/wpt#33746
• Implementation bugs are filed:
  • Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1254926
  • Firefox: N/A
  • Safari: https://bugs.webkit.org/show_bug.cgi?id=239729

(See WHATWG Working Mode: Changes for more details.)

---

/browsing-the-web.html ( diff )

[annevk]

It's weird that hashchange wouldn't happen in the same task, but from the tests it does look like that is what happens.

One thing I wondered about while reading this is when "restore persisted state" runs. The way it's written now you could observe from the popstate event listener that nothing happened. But wouldn't it make more sense for it to run first?

[domenic]

I'm not really sure what makes more sense, but it generally seems interoperable that in the cases this change doesn't touch (i.e. cases where popstate would be after the load event anyway in Chromium and WebKit) everyone uses the order [popstate, scroll restoration, hashchange]: test results.

I guess we should try to expand the linked tests to also include scroll restoration if possible... seems hard though since all our traversal tests so far result in load being the first event.