This question may sound weird, because most of the time popstate is fired synchronously as users press the back button.
However, W3C spec states that a UA (browser) is allowed to queue popstate when traversing history (see item 14), ie. popstate
is fired asynchronously (even though URL has changed at this point).
Browser vendors interpret and implement this spec differently. Mozilla decides Firefox should be able to fire popstate
before load
, and for good reasons, so that slow images will not block popstate
.
Chrome/Safari decides otherwise, and it leads our problem:
When managing history for a web app, it's often desirable to kick off history management as soon as possible, eg. at DOMContentLoaded
instead of load
. But in return, users are not able to back out of any pushState
, because all popstate
are queued until load
.
We are seeking advices for ways to handle such scenario. I come up with a few myself:
- Lazyload images, so
load
can fire ASAP. - Block UI until
load
is fired. - Init framework on
load
instead ofDOMContentLoaded
.
Are there better solutions?
Update: Things get ugly when there are ajax that fire before load
, if those request result in DOM change, and DOM change happens to have some images, load
is delayed until those images are loaded/timeout, meaning popstate
is queued for even longer.
Update 2: To add a simple demo for it, visit this jsbin page with chrome and see popstate
will be blocked until load
is fired. You can compare result between cached image and uncached image.