Intent to Implement: Fire visibilitychange event on document unloading

[Kinuko Yasuda]

Contact emails

kin...@chromium.org, igri...@chromium.org

Spec

http://w3c.github.io/page-visibility/#reacting-to-visibility-changes

Summary

visibilitychange event should fire as part of unload process and document.visibilityState should report 'hidden'.

Motivation

This aligns our behavior to match Firefox and the spec. This should also give Web developers a more reliable signal about when the site should save user's progress and app state, because other unload-related signals (i.e. pagehide, beforeunload and unload) may not fire on mobile platforms in various cases (more details are discussed in this blog past).

Interoperability risk

Firefox: Shipped

Edge: bug is filed

Safari/WebKit: No public signals (bug is filed)

Web developers: No signals

Compatibility risk

Low risk. It's already shipped in Firefox.  Edge is showing an interest to address this on public github discussion (https://github.com/w3c/page-visibility/issues/18#issuecomment-156031906).

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no.

Yes

OWP launch tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=594049

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5758579827015680

Requesting approval to ship?

No

[Philip Jägenstedt]

This makes a lot of sense, and a quick glance at the spec doesn't reveal anything strange. HTML's unloading document visibility change steps is used in a way which I suspect cannot exactly match the implementation, if that's correct maybe you can file a spec issue when implementing. It's pretty clear how it's supposed to work in any event.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Jochen Eisinger]

what additional data do you expect to gather before you want to ship this? Or, why not just make this an intent to implement & ship?

[Kinuko Yasuda]

On Fri, Mar 11, 2016 at 8:25 PM, Jochen Eisinger <joc...@chromium.org> wrote:

what additional data do you expect to gather before you want to ship this? Or, why not just make this an intent to implement & ship?

We're afraid that this might be adding another point where we have undesirable crashes / UX issues / performance issues like we had in unload, and we want to add proper API restrictions (or at least do a bit more investigation) before shipping.  Basically we plan to apply the same API restrictions as unload handlers, i.e. disallowing modal dialogs etc in the handler, but there're still some APIs that can run on unload (and therefore in visibilitychange@unload) that could run nested loops.