Proposal: change the ordering of visibilitychange and pagehide when unloading a page

[philipwalton]

(Moving the discussion from page-visibility #39 to here.)

The current ordering of pagehide and visibilitychange during a document unload complicates our proposed Lifecycle states/event flow because the ordering of lifecycle events can be different depending on whether the page was unloaded from the foreground or the background.

Given the assumption that the flow through Page Lifecycle states generally takes this path:

ACTIVE → PASSIVE → HIDDEN → TERMINATED/FROZEN

In the foreground case, if the visibilitychange event fires after the pagehide event (currently spec'ed behavior), then the implication is either:

• The TERMINATED/FROZEN states can come before the HIDDEN state in some cases
• The visibilitychange and pagehide events do not necessarily signal changes to the HIDDEN and TERMINATED/FROZEN states (respectively).

This complicates things for developers.

If we update the order in the spec, these complications go way and developers can rely on a consistent event firing order in all unload situations, which allows them to more easily follow best-practice guidance for the type of work to do in each state.

Furthermore, the new freeze event is required to run after the visibilitychange event when a document is unloading, and for future compatibility it would make sense that pagehide (persisted:true) fires immediately before freeze.

/cc @spanicker

[domenic]

Relevant implementer thoughts:

• Why does visibilitychange fire after pagehide in the unload flow? w3c/page-visibility#39 (comment): Gecko thinks it should be fine, although we need to be careful about the unload algorithm, in particular impact on fullscreen.
• Why does visibilitychange fire after pagehide in the unload flow? w3c/page-visibility#39 (comment) and elsehwere: Blink is game to try
• No comments from EdgeHTML or WebKit.

So the biggest TODO is the concerns around unload.

[rakina]

I recently looked at the unload a Document steps and this change sounds simple. We probably need some changes to the steps in the Page Visibility spec to not reference the "unload" event as it does right now, and instead refer to "unload a Document" which covers bfcache too (we won't fire the unload event in bfcache's case - yes, it is confusing and we'll probably rename "unload a Document" to something like "navigate away from Document" or something)

The fullscreen unload step that @smaug---- mentioned should probably be changed to mention unload a Document instead (also unless I'm missing something this seems orthogonal to the change we wanted for this issue, so can be fixed separately).

So the changes needed are:

1. Swap the order of pagehide and "unloading document visibility change steps" in HTML spec.
2. Rename "unload a Document" to a better name in HTML spec
3. Change Page Visibility spec to refer to the newly renamed "unload a Document" steps
4. Change fullscreen spec to refer to the newly renamed "unload a Document" steps

[domenic]

Merged #5928! I'll leave this open to track items (2)-(4) in @rakina's list.

[sideshowbarker]

We probably need some changes to the steps in the Page Visibility spec to not reference the "unload" event as it does right now, and instead refer to "unload a Document" which covers bfcache too

That sounds necessary. It came up when chatting with @cdumez about https://webkit.org/b/151234 — he said:

I am also firing the visibilitychange event when coming out of the back/forward cache. Not sure if this is spec’d but this makes sense and this is Firefox’s behavior

So I’d be happy to raise a PR or bug myself against the Page Visibility spec about this. Should I?

[rakina]

So I’d be happy to raise a PR or bug myself against the Page Visibility spec about this. Should I?

That would be great, thank you!

Although, I think the part that @cdumez talked about in that comment is not related to unload (it's about recovering a document on bfcache/history traversal) which is already covered by session history document visibility change steps