Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why does visibilitychange fire after pagehide in the unload flow? #39

Closed
philipwalton opened this issue Apr 26, 2018 · 11 comments

Comments

Projects
None yet
6 participants
@philipwalton
Copy link
Member

commented Apr 26, 2018

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 visibilitychangepagehide.

  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 pagehidevisibilitychange.

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

This comment has been minimized.

Copy link
Member

commented May 3, 2018

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

This comment has been minimized.

Copy link
Member Author

commented May 4, 2018

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

This comment has been minimized.

Copy link
Member

commented May 4, 2018

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

This comment has been minimized.

Copy link

commented May 4, 2018

@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

This comment has been minimized.

Copy link

commented May 7, 2018

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

This comment has been minimized.

Copy link

commented May 9, 2018

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

@spanicker

This comment has been minimized.

Copy link

commented May 15, 2018

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

@smaug----

This comment has been minimized.

Copy link

commented May 16, 2018

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

This comment has been minimized.

Copy link

commented Jun 29, 2018

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 toddreifsteck added this to the Level 3 milestone Aug 20, 2018

@toddreifsteck

This comment has been minimized.

Copy link
Member

commented Aug 20, 2018

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

@philipwalton

This comment has been minimized.

Copy link
Member Author

commented Aug 23, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.