Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Why does visibilitychange fire after pagehide in the unload flow? #39
The current ordering of
The reason is the ordering of
Wouldn't it make more sense if
Since pagehide is associated with the FROZEN state (for bfcache supporting browsers), and visiblitychange is associated with the HIDDEN state, the current ordering of events suggests that the lifecycle state of a page can transition from ACTIVE to FROZEN to HIDDEN, which doesn't make sense since we only want to freeze hidden tabs.
Does anyone here remember why this ordering was chosen? Would anyone object to changing the ordering in the spec?
(Related dicussion WICG/page-lifecycle#7).
I don't recall any particular reason for why this ordering was chosen. My guess is that it simply wasn't a constraint or criteria when we specced this.
If we wanted to update this logic, you'd have to update the HTML spec and swap order of steps 5 and 6.
My guess is this wouldn't break many (or any) sites or analytics libraries based on the fact that, until recently, not all browsers actually fired
My sense is most code has to determine page unload status by listening to a number of different events (
I think it should be fine, and looking at the Gecko implementation, the change should be easy https://searchfox.org/mozilla-central/rev/00dd116638001772fe354b081353b73f1cad405d/dom/base/nsDocument.cpp#8548,8561
But that code made me look at fullscreen spec, and perhaps we'll need to update that too "Whenever the unloading document cleanup steps run with a document, fully exit fullscreen document." That happens quite late during unload.
Basically someone needs to take a look at the whole unload algorithm https://html.spec.whatwg.org/multipage/browsing-the-web.html#unload-a-document and figure out what all needs to be changed and whether changes are actually feasible.