Why does visibilitychange fire after pagehide in the unload flow?

[philipwalton]

The current ordering of pagehide and visibilitychange during a page unload complicates our proposed flow of Lifecycle states for the Lifecycle API.

The reason is the ordering of pagehide and visibilitychange events can be inverted, depending on what the user does. Consider these two examples:

1. The user loads a page in Tab A and then switches to a new tab B. Later, they close tab A without refocusing it. In this case the ordering of events fired on tab A is visibilitychange → pagehide.

2. The user loads a page in Tab A and then navigates to a new page from a link. In this case the ordering of events fired on tab A is pagehide → visibilitychange.

Wouldn't it make more sense if visibilitychange always fired before pagehide?

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?

https://html.spec.whatwg.org/multipage/browsing-the-web.html#unloading-documents

(Related dicussion WICG/page-lifecycle#7).

[igrigorik]

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.

• Need to make make sure this change doesn't affect any other specs relying on "unloading document visibility change steps" hook.
• Could this break any existing clients / analytics libraries?

[philipwalton]

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 visibilitychange when the page was unloading (@toddreifsteck actually made this point when we discussed this issue on the last call).

My sense is most code has to determine page unload status by listening to a number of different events (pagehide, visibilitychange, unload), so it's unlikely that changing one of them would cause breakage.

[igrigorik]

Fair enough. I don't have any objections to making this change. That said, this is an update to the HTML spec, so I'll defer to the editors there.

[spanicker]

@domenic could we send a patch to update the ordering in the HTML spec? or do we need a new bug on html repo first?

[domenic]

Sending a patch to HTML sounds great! It'll need publicly-expressed multi-implementer interest to land; you can gather that on the PR or in this issue. (Also it will need web platform tests.)

[spanicker]

@smaug--- @toddreifsteck - could you comment for implementer interest.
If there is agreement, I will make the change.

[spanicker]

(Oops, I had the wrong git handle for Olli)
@smaug---- any thoughts on this?

[smaug----]

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.

[spanicker]

Would it make sense to make the code change in Chrome (before spec change) and see if anything breaks, although I'm fine with proceeding with spec change based on comments in this thread.

[toddreifsteck]

@philipwalton Per WG call, Could you work with folks to move this issue to HTML5 spec as it tracks the ordering of events.

[philipwalton]

Filed whatwg/html#3957.