Intent to Prototype and Ship: Update visibilityState before firing pagehide

235 views
Skip to first unread message

Rakina Zata Amni

unread,
Sep 22, 2020, 5:51:57 AM9/22/20
to blink-dev, Philip Walton

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


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


Yoav Weiss

unread,
Sep 24, 2020, 5:09:23 AM9/24/20
to Rakina Zata Amni, blink-dev, Philip Walton
This seems like a positive change that would make working with visibilitychange and pagehide events easier. Thanks for working on this!

On Tue, Sep 22, 2020 at 11:51 AM Rakina Zata Amni <rak...@chromium.org> wrote:

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


What's the risk from a compatibility perspective? Do you expect content to break due to this reordering?
 

Firefox: Public support (comment)

Safari: No signals


Could you ask for official 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


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

Rakina Zata Amni

unread,
Sep 28, 2020, 1:26:05 AM9/28/20
to blink-dev, yo...@yoav.ws, blink-dev, Philip Walton, Rakina Zata Amni
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:

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 :)


Yoav Weiss

unread,
Sep 28, 2020, 2:38:14 AM9/28/20
to Rakina Zata Amni, blink-dev, Philip Walton
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:

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.


> 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 :)

That signal seems sufficient to me.

Rakina Zata Amni

unread,
Sep 28, 2020, 2:48:02 AM9/28/20
to Yoav Weiss, blink-dev, Philip Walton
On Mon, Sep 28, 2020 at 3:38 PM Yoav Weiss <yo...@yoav.ws> wrote:


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:

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.

That makes sense, I think we can wait until we have a better understanding. Will add those metrics and report back. Thanks!

Mike West

unread,
Oct 29, 2020, 3:05:19 PM10/29/20
to blink-dev, Rakina Zata Amni, blink-dev, Philip Walton, yo...@yoav.ws
Hello!

Have y'all gotten the data (and therefore understanding) that you were looking for?

-mike

Rakina Zata Amni

unread,
Nov 2, 2020, 9:32:34 AM11/2/20
to Mike West, blink-dev, Philip Walton, yo...@yoav.ws
Thanks for following up! So after further discussions, it looks like we don't currently have a need for this anymore. So we're not pursuing this actively for now. Sorry for the noise, I'll make sure this doesn't happen again :)

Manuel Rego Casasnovas

unread,
Nov 5, 2020, 3:20:00 PM11/5/20
to Rakina Zata Amni, Mike West, blink-dev, Philip Walton, yo...@yoav.ws
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?

Thanks,
Rego

On 02/11/2020 15:32, Rakina Zata Amni wrote:
> Thanks for following up! So after further discussions, it looks like we
> don't currently have a need for this anymore. So we're not pursuing this
> actively for now. Sorry for the noise, I'll make sure this doesn't
> happen again :)
>
> On Fri, Oct 30, 2020 at 4:05 AM Mike West <mk...@chromium.org
> <mailto:mk...@chromium.org>> wrote:
>
> Hello!
>
> Have y'all gotten the data (and therefore understanding) that you
> were looking for?
>
> -mike
>
> On Monday, September 28, 2020 at 8:48:02 AM UTC+2 Rakina Zata Amni
> wrote:
>
> On Mon, Sep 28, 2020 at 3:38 PM Yoav Weiss <yo...@yoav.ws> wrote:
>
>
>
> 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.
>
>
> That makes sense, I think we can wait until we have a better
> understanding. Will add those metrics and report back. Thanks!
>  
>
>
> > Could you ask for official signals
> <https://docs.google.com/document/d/1xkHRXnFS8GDqZi7E0SSbR3a7CZsGScdxPUWBsNgo-oo/edit#heading=h.tgzhprxcmw4u>?
>
> 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 :)
>
> That signal seems sufficient to me.
>  
>
>
> On Thursday, September 24, 2020 at 6:09:23 PM UTC+9
> yo...@yoav.ws wrote:
>
> This seems like a positive change that would make
> working with visibilitychange and pagehide events
> easier. Thanks for working on this!
>
> On Tue, Sep 22, 2020 at 11:51 AM Rakina Zata Amni
> <rak...@chromium.org> wrote:
>
>
> Contact emails
>
> rak...@chromium.org, philip...@google.com
>
>
> Explainer
>
> No explainer, but see proposal
> <https://github.com/whatwg/html/issues/3957>.
>
>
> Spec
>
> https://github.com/whatwg/html/pull/5928 
>
>
> Summary
>
> Currently when unloading a document
> <https://html.spec.whatwg.org/multipage/browsing-the-web.html#unload-a-document>,
> we would fire pagehide
> <https://developer.mozilla.org/en-US/docs/Web/API/Window/pagehide_event>before
> running “unloading document visibility change
> steps
> <https://html.spec.whatwg.org/multipage/browsing-the-web.html#unloading-document-visibility-change-steps>”
> (which includes firing the visibilitychange
> <https://developer.mozilla.org/en-US/docs/Web/API/Document/visibilitychange_event>event
> if needed). We will swap this ordering, so that
> we would first run “unloading document
> visibility change steps
> <https://html.spec.whatwg.org/multipage/browsing-the-web.html#unloading-document-visibility-change-steps>”
> before firing pagehide
> <https://developer.mozilla.org/en-US/docs/Web/API/Window/pagehide_event>.
>
>
> Motivation
>
> Updating visibility before firing pagehide
> simplifies Page Lifecycle state transitions
> <https://developers.google.com/web/updates/2018/07/page-lifecycle-api#overview_of_page_lifecycle_states_and_events>,
> as this will guarantee that a page will always
> get into the “hidden” state before transitioning
> into the “terminated” or “frozen” state. See
> proposal
> <https://github.com/whatwg/html/issues/3957>for
> more details.
>
> This is also consistent with the pageshow
> <https://developer.mozilla.org/en-US/docs/Web/API/Window/pageshow_event>event:
> we will run “session history document visibility
> change steps
> <https://html.spec.whatwg.org/multipage/browsing-the-web.html#session-history-document-visibility-change-steps>”
> before firing pageshow
> <https://html.spec.whatwg.org/multipage/browsing-the-web.html#history-traversal:event-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
> <https://github.com/w3c/page-visibility/issues/39#issuecomment-389486782>).
>
>
> What's the risk from a compatibility perspective? Do
> you expect content to break due to this reordering?
>  
>
>
> Firefox: Public support (comment
> <https://github.com/w3c/page-visibility/issues/39#issuecomment-389486782>)
>
> Safari: No signals
>
>
> Could you ask for official signals
> <https://docs.google.com/document/d/1xkHRXnFS8GDqZi7E0SSbR3a7CZsGScdxPUWBsNgo-oo/edit#heading=h.tgzhprxcmw4u>?
>  
>
> 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
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
>
> Yes (see CL
> <https://chromium-review.googlesource.com/c/chromium/src/+/2422109>)
>
>
> Link to entry on the feature dashboard
> <https://www.chromestatus.com/>
>
> 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
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACPC1r5M-R%3Dw8UD_Ueqai7V0jpXdc3ooO0TnNW0OnvMEmYq4ig%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
> --
> 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
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACPC1r5TSDcDnC2MMc2ovhq0YjSxyAMA%2BzCpF0nTnhiSJfFt3w%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACPC1r5TSDcDnC2MMc2ovhq0YjSxyAMA%2BzCpF0nTnhiSJfFt3w%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Rakina Zata Amni

unread,
Nov 5, 2020, 5:13:27 PM11/5/20
to Manuel Rego Casasnovas, Mike West, blink-dev, Philip Walton, yo...@yoav.ws
On Fri, Nov 6, 2020 at 5:19 AM Manuel Rego Casasnovas <re...@igalia.com> wrote:
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?

Sorry for the confusion! That was merged, but was later reverted in https://github.com/whatwg/html/pull/5949. 
Reply all
Reply to author
Forward
0 new messages