Contact emails
rak...@chromium.org, philip...@google.com
Explainer
No explainer, but see proposal.
Spec
https://github.com/whatwg/html/pull/5928
Summary
Currently when unloading a document, we would fire pagehide before running “unloading document visibility change steps” (which includes firing the visibilitychange event if needed). We will swap this ordering, so that we would first run “unloading document visibility change steps” before firing pagehide.
Motivation
This is also consistent with the pageshow event: we will run “session history document visibility change steps” before firing pageshow.
Risks
Interoperability and Compatibility
Blink will be the first to implement the ordering change, but this should be easy to implement in other browsers quickly (see comment).
Firefox: Public support (comment)
Safari: No signals
Web / Framework developers: No signals
Ergonomics/Activation
Both “pagehide” and “visibilitychange” events already exist and this only changes the ordering of the event, so ergonomics/activation should not be a problem. It is also unlikely that the ordering change of “pagehide” and “visibilitychange” events would break pages, as it is already possible for “visibilitychange” to fire before “pagehide” (e.g. when a backgrounded tab does a navigation).
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
Yes (see CL)
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5279330336768000
Requesting approval to ship?
Yes
Contact emails
rak...@chromium.org, philip...@google.com
Explainer
No explainer, but see proposal.
Spec
https://github.com/whatwg/html/pull/5928
Summary
Currently when unloading a document, we would fire pagehide before running “unloading document visibility change steps” (which includes firing the visibilitychange event if needed). We will swap this ordering, so that we would first run “unloading document visibility change steps” before firing pagehide.
Motivation
Updating visibility before firing pagehide simplifies Page Lifecycle state transitions, as this will guarantee that a page will always get into the “hidden” state before transitioning into the “terminated” or “frozen” state. See proposal for more details.This is also consistent with the pageshow event: we will run “session history document visibility change steps” before firing pageshow.
Risks
Interoperability and Compatibility
Blink will be the first to implement the ordering change, but this should be easy to implement in other browsers quickly (see comment).
Web / Framework developers: No signals
Ergonomics/Activation
Both “pagehide” and “visibilitychange” events already exist and this only changes the ordering of the event, so ergonomics/activation should not be a problem. It is also unlikely that the ordering change of “pagehide” and “visibilitychange” events would break pages, as it is already possible for “visibilitychange” to fire before “pagehide” (e.g. when a backgrounded tab does a navigation).
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
Yes (see CL)
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5279330336768000
Requesting approval to ship?
Yes
--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACPC1r5M-R%3Dw8UD_Ueqai7V0jpXdc3ooO0TnNW0OnvMEmYq4ig%40mail.gmail.com.
I haven't sent a request through the official signal channels for webkit, but got a response on a Webkit bug I filed for this (https://bugs.webkit.org/show_bug.cgi?id=216917#c1). Looks like Safari will follow Chrome and Firefox's behavior if we do decide to change it (because they've only recently implemented this anyways). I can send an actual request for official signal if needed, let me know :)
Sorry for the late reply, this missed my inbox somehow.> What's the risk from a compatibility perspective? Do you expect content to break due to this reordering?I think it's a fairly low risk change, due to these points:
- It's already possible for visibilityState to be hidden and visibilitychange to be fired before pagehide, if a tab is already backgrounded before navigation. So sites should already handle this case.
- Safari have not implemented visibilitychange on navigation until last week (see: https://bugs.webkit.org/show_bug.cgi?id=151234)
- Back in 2018 we assessed since it was a new API it won't be a controversial change, and the usage for page visibility API hasn't changed much from 2018. https://www.chromestatus.com/metrics/feature/timeline/popularity/196
If this still sounds risky, I guess we can also add metrics to track e.g. usage of visibilityState within pagehide handlers before deciding to ship.
> Could you ask for official signals?I haven't sent a request through the official signal channels for webkit, but got a response on a Webkit bug I filed for this (https://bugs.webkit.org/show_bug.cgi?id=216917#c1). Looks like Safari will follow Chrome and Firefox's behavior if we do decide to change it (because they've only recently implemented this anyways). I can send an actual request for official signal if needed, let me know :)
On Mon, Sep 28, 2020 at 7:26 AM Rakina Zata Amni <rak...@chromium.org> wrote:Sorry for the late reply, this missed my inbox somehow.> What's the risk from a compatibility perspective? Do you expect content to break due to this reordering?I think it's a fairly low risk change, due to these points:
- It's already possible for visibilityState to be hidden and visibilitychange to be fired before pagehide, if a tab is already backgrounded before navigation. So sites should already handle this case.
- Safari have not implemented visibilitychange on navigation until last week (see: https://bugs.webkit.org/show_bug.cgi?id=151234)
- Back in 2018 we assessed since it was a new API it won't be a controversial change, and the usage for page visibility API hasn't changed much from 2018. https://www.chromestatus.com/metrics/feature/timeline/popularity/196
If this still sounds risky, I guess we can also add metrics to track e.g. usage of visibilityState within pagehide handlers before deciding to ship.While the counters haven't changed, they are very high, so I wouldn't take that as a strong signal that this is safe to modify.Adding use counters (and/or doing an HA search, if time is pressing) sounds like a good path forward.
So it looks like you're abandoning this change, but the spec change has
been already merged https://github.com/whatwg/html/pull/5928. Could you
please clarify what's going on?