Intent to Ship: Page Lifecycle - to enable system initiated Discarding & Freezing

[Shubhie Panicker]

Contact emails

pani...@chromium.org, fme...@chromium.org

Explainer

https://github.com/WICG/page-lifecycle/blob/master/README.md

Spec

https://wicg.github.io/page-lifecycle/spec.html

Completed TAG review for proposal.

Pending TAG review for spec.

Summary

Application lifecycle is a key way that modern OS' manage resources. On Android, iOS and recent Windows, apps can be started and stopped at will by the platform. This lets the platform streamline and re-allocate resources where they best benefit the user.

On the web, there is no such lifecycle, and apps can be alive indefinitely; with large numbers of web apps (and tabs) running, this causes critical resources such as memory, CPU, battery, network etc to get oversubscribed, leading to a bad end user experience.

The Page Lifecycle API (and umbrella Lifecycle project) addresses this by:

• defining the lifecycle of a web page -- including web pages in background

• formalizing important system interventions necessary for resource reallocation to improve foreground responsiveness:

• discarding for memory

• freezing (i.e. CPU suspension) for battery, data etc.

• providing developers with APIs as signals for transitions between the lifecycle states

There is ongoing (future) work to provide lifecycle-compatible APIs that will allow key capabilities to work even when the app is backgrounded or frozen.

Link to “Intent to Implement”

https://groups.google.com/a/chromium.org/d/msg/blink-dev/1WFVPbRL640/TPPG9gs5AwAJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Debuggability

chrome://discards provides hooks for lifecycle interventions: freezing and discarding; it can be used to trigger them and check the behavior of the application. This functionality could also be added to DevTools when the APIs start getting used (as desktop interventions roll out).

Risks

Interoperability and Compatibility

Interop risk is medium, this API is applicable for browsers who want to do interventions like proactive discarding and freezing for background web pages.

Compat risk: low.

There isn’t compat risk with simply shipping the APIs (this intent). There will be some compat risk as actual interventions for proactive Discarding and Freezing are shipped. The planned interventions try to minimize this risk, and will have their own Intent to Ship (example).

Edge: Public support

Firefox: No public statement yet; though they have been very active in providing feedback and have helped shape and refine the API.

Safari: No signals

Web developers: Facebook, Akamai, AMP, Google Docs etc. are supportive of this.

On the whole, browser vendors and developers are onboard that this is a positive change for the web platform; there is agreement that browsers should have autonomy to move apps to DISCARDED (Tab discarding) and FROZEN (CPU suspension) lifecycle states and web apps should receive signals when these lifecycle state transitions occur.

Ergonomics

Are there any other platform APIs this feature will frequently be used in tandem with?

Yes, it will be used along with other existing lifecycle APIs such as unload, beforeunload, load, pagehide, pageshow, pagevisibility (hidden / visible) etc.

Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?

No, quite the contrary.

Activation

Will it be challenging for developers to take advantage of this feature immediately, as-is?

No.

Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?

Yes.

Philip Walton is actively working on activation efforts: MDN article, /web post etc. A lot of this documentation will benefit existing apps, as it has recommendations for existing callbacks (eg. pagevisibility, pagehide etc).

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

A web-platform-test for this feature is currently not feasible with the existing infrastructure. The APIs are called when the system decides to transition the Document from one Lifecycle State to another. The new API is triggered on the transition to FROZEN and DISCARDED states. Those transitions cannot be stimulated or forced in a predictive manner. Each vendor can implement their own heuristics on when to transition to those states.

We are working on adding a WebDriver API to freeze and resume a page (issue).

We already added support in chrome’s devtools protocol (Page.setWebLifecycleState), and have the following chromium tests as a first step towards wpt testing.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5644602711212032

[Yoav Weiss]

Thanks for working on this :) Seems like an important addition to the platform.

On Tue, May 22, 2018 at 8:17 PM Shubhie Panicker <pani...@chromium.org> wrote:

Contact emails

pani...@chromium.org, fme...@chromium.org

Explainer

https://github.com/WICG/page-lifecycle/blob/master/README.md

Spec

https://wicg.github.io/page-lifecycle/spec.html

Completed TAG review for proposal.

Pending TAG review for spec.

How do those TAG reviews differ? Did much change between the first review and the second one?

 

Summary

Application lifecycle is a key way that modern OS' manage resources. On Android, iOS and recent Windows, apps can be started and stopped at will by the platform. This lets the platform streamline and re-allocate resources where they best benefit the user.

On the web, there is no such lifecycle, and apps can be alive indefinitely; with large numbers of web apps (and tabs) running, this causes critical resources such as memory, CPU, battery, network etc to get oversubscribed, leading to a bad end user experience.

The Page Lifecycle API (and umbrella Lifecycle project) addresses this by:

• defining the lifecycle of a web page -- including web pages in background

• formalizing important system interventions necessary for resource reallocation to improve foreground responsiveness:

• discarding for memory

• freezing (i.e. CPU suspension) for battery, data etc.

• providing developers with APIs as signals for transitions between the lifecycle states

There is ongoing (future) work to provide lifecycle-compatible APIs that will allow key capabilities to work even when the app is backgrounded or frozen.

Link to “Intent to Implement”

https://groups.google.com/a/chromium.org/d/msg/blink-dev/1WFVPbRL640/TPPG9gs5AwAJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Debuggability

chrome://discards provides hooks for lifecycle interventions: freezing and discarding; it can be used to trigger them and check the behavior of the application. This functionality could also be added to DevTools when the APIs start getting used (as desktop interventions roll out).

Risks

Interoperability and Compatibility

Interop risk is medium, this API is applicable for browsers who want to do interventions like proactive discarding and freezing for background web pages.

IIUC, this intent covers 2 new events and 1 readonly attribute.

From the explainer:

"""

onfreeze is fired to signal transition to FROZEN.

onresume is fired to signal transition out of FROZEN. This will be used to undo what was done in onfreeze above.

On DISCARDED -> ACTIVE, an attribute called wasDiscarded is added to the Document. This will be used to restore view state , when the user revisits a discarded tab.

onfreeze is also fired before transition to BFCACHE (before pagehide is fired) and onresume is also fired on transition out of BFCACHE (after pageshow is fired). 

"""

Since no other vendors currently implement, how confident are we that these will not change?

Can content somehow rely on this API and break if it will change in the future (or if not implemented)?

I can't think of ways content will do that, which makes me want to rank the risk as "low". But maybe I'm being optimistic :D

Some information that may help to clarify that picture: how do we expect devs to use the new "onfreeze" and "onresume" events? What actions would they normally want to take when these events fire? What are the consequences of these events missing in non-supporting browsers?

Compat risk: low.

There isn’t compat risk with simply shipping the APIs (this intent). There will be some compat risk as actual interventions for proactive Discarding and Freezing are shipped. The planned interventions try to minimize this risk, and will have their own Intent to Ship (example).

Just to make sure, this intent does not change the behavior of any of the currently shipping lifecycle events, right?

 

Edge: Public support

Can you link to support from Edge? Do you know if they intend to follow with an implementation?

 

Firefox: No public statement yet; though they have been very active in providing feedback and have helped shape and refine the API.

Safari: No signals

Web developers: Facebook, Akamai, AMP, Google Docs etc. are supportive of this.

On the whole, browser vendors and developers are onboard that this is a positive change for the web platform; there is agreement that browsers should have autonomy to move apps to DISCARDED (Tab discarding) and FROZEN (CPU suspension) lifecycle states and web apps should receive signals when these lifecycle state transitions occur.

Ergonomics

Are there any other platform APIs this feature will frequently be used in tandem with?

Yes, it will be used along with other existing lifecycle APIs such as unload, beforeunload, load, pagehide, pageshow, pagevisibility (hidden / visible) etc.

Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?

No, quite the contrary.

Activation

Will it be challenging for developers to take advantage of this feature immediately, as-is?

No.

Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?

Yes.

Philip Walton is actively working on activation efforts: MDN article, /web post etc. A lot of this documentation will benefit existing apps, as it has recommendations for existing callbacks (eg. pagevisibility, pagehide etc).

Can the feature be polyfilled? Does it make sense to polyfill it? (i.e. should devs rely on the feature being implemented, either natively or via polyfill?)

 

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

A web-platform-test for this feature is currently not feasible with the existing infrastructure. The APIs are called when the system decides to transition the Document from one Lifecycle State to another. The new API is triggered on the transition to FROZEN and DISCARDED states. Those transitions cannot be stimulated or forced in a predictive manner. Each vendor can implement their own heuristics on when to transition to those states.

We are working on adding a WebDriver API to freeze and resume a page (issue).

We already added support in chrome’s devtools protocol (Page.setWebLifecycleState), and have the following chromium tests as a first step towards wpt testing.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5644602711212032

--
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/CAK7ODi885Vr5OkcM_DrkLcUdNYSTG2xBKUrRXhS2gihUcPdbcg%40mail.gmail.com.

[sligh...@chromium.org]

Hey all,

Excited to see so much progress on this API! We discussed this intent at today's API OWNERS meeting and per that conversation, I'm going to hold off on LGTMing until the follow-up conversation at the TAG happens regarding the shape of the API.

Shubie: is there time pressure, e.g. from partners, to see this launch quickly?

Thanks again, and excited to see this move forward.

Regards

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Shubhie Panicker]

On Thu, May 24, 2018 at 9:40 AM, <sligh...@chromium.org> wrote:

Hey all,

Excited to see so much progress on this API! We discussed this intent at today's API OWNERS meeting and per that conversation, I'm going to hold off on LGTMing until the follow-up conversation at the TAG happens regarding the shape of the API.

Shubie: is there time pressure, e.g. from partners, to see this launch quickly?

The "time pressure" here is to get this in time for (first phase) proactive discarding intervention which is expected to ship in M69.

Waiting for TAG discussion sounds reasonable though.

Yeah it sounds like low is correct, I tend to get confused whether interop risk is about "what if other browsers don't implement it" vs. "what is the consequence of them not implementing it".

How do we expect devs to use the callbacks:

• Teardown / setup of expensive resources such as IDB and Web Locks
  
• coordinate app state across these tabs (for multi-tab apps eg. Docs)
  
• final communication to server; analytics
• testing for handling of freezing

There isn't much consequence of these events missing in other browsers, as those browsers are not doing proactive interventions like freezing & discarding.

Most browsers already does some kind of reactive intervention in extreme cases (eg. critical memory pressure) -- but the API is to help make these much more normal and prevalent for proactive resource re-allocation. 

 

Compat risk: low.

There isn’t compat risk with simply shipping the APIs (this intent). There will be some compat risk as actual interventions for proactive Discarding and Freezing are shipped. The planned interventions try to minimize this risk, and will have their own Intent to Ship (example).

Just to make sure, this intent does not change the behavior of any of the currently shipping lifecycle events, right?

That is right.

(I'll send a separate intent for a change we want to make to ordering of pagevisibility & pagehide)

 

Edge: Public support

Can you link to support from Edge? Do you know if they intend to follow with an implementation?

Travis was going to write something up, I believe. Otherwise I can link to our discussion (private thread) by forwarding it to a public list :)

 

 

Firefox: No public statement yet; though they have been very active in providing feedback and have helped shape and refine the API.

Safari: No signals

Web developers: Facebook, Akamai, AMP, Google Docs etc. are supportive of this.

On the whole, browser vendors and developers are onboard that this is a positive change for the web platform; there is agreement that browsers should have autonomy to move apps to DISCARDED (Tab discarding) and FROZEN (CPU suspension) lifecycle states and web apps should receive signals when these lifecycle state transitions occur.

Ergonomics

Are there any other platform APIs this feature will frequently be used in tandem with?

Yes, it will be used along with other existing lifecycle APIs such as unload, beforeunload, load, pagehide, pageshow, pagevisibility (hidden / visible) etc.

Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?

No, quite the contrary.

Activation

Will it be challenging for developers to take advantage of this feature immediately, as-is?

No.

Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?

Yes.

Philip Walton is actively working on activation efforts: MDN article, /web post etc. A lot of this documentation will benefit existing apps, as it has recommendations for existing callbacks (eg. pagevisibility, pagehide etc).

Can the feature be polyfilled? Does it make sense to polyfill it? (i.e. should devs rely on the feature being implemented, either natively or via polyfill?)

I'm a bit confused by this question.

This cannot be polyfilled as if the browser triggers freezing and discarding there is no way for JS to detect this and provide a callback (onfreeze) or signal for being discarded (wasDiscarded).

[Yoav Weiss]

Thanks for clarifying!

So most risk would be from future changes of this API and need for content to adapt. Seems manageable, especially after feedback from TAG and other vendors.

 

 

Compat risk: low.

There isn’t compat risk with simply shipping the APIs (this intent). There will be some compat risk as actual interventions for proactive Discarding and Freezing are shipped. The planned interventions try to minimize this risk, and will have their own Intent to Ship (example).

Just to make sure, this intent does not change the behavior of any of the currently shipping lifecycle events, right?

That is right.

(I'll send a separate intent for a change we want to make to ordering of pagevisibility & pagehide)

 

Edge: Public support

Can you link to support from Edge? Do you know if they intend to follow with an implementation?

Travis was going to write something up, I believe. Otherwise I can link to our discussion (private thread) by forwarding it to a public list :)

Let's wait for Travis' feedback :)

 

 

 

Firefox: No public statement yet; though they have been very active in providing feedback and have helped shape and refine the API.

Safari: No signals

Web developers: Facebook, Akamai, AMP, Google Docs etc. are supportive of this.

On the whole, browser vendors and developers are onboard that this is a positive change for the web platform; there is agreement that browsers should have autonomy to move apps to DISCARDED (Tab discarding) and FROZEN (CPU suspension) lifecycle states and web apps should receive signals when these lifecycle state transitions occur.

Ergonomics

Are there any other platform APIs this feature will frequently be used in tandem with?

Yes, it will be used along with other existing lifecycle APIs such as unload, beforeunload, load, pagehide, pageshow, pagevisibility (hidden / visible) etc.

Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?

No, quite the contrary.

Activation

Will it be challenging for developers to take advantage of this feature immediately, as-is?

No.

Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?

Yes.

Philip Walton is actively working on activation efforts: MDN article, /web post etc. A lot of this documentation will benefit existing apps, as it has recommendations for existing callbacks (eg. pagevisibility, pagehide etc).

Can the feature be polyfilled? Does it make sense to polyfill it? (i.e. should devs rely on the feature being implemented, either natively or via polyfill?)

I'm a bit confused by this question.

This cannot be polyfilled as if the browser triggers freezing and discarding there is no way for JS to detect this and provide a callback (onfreeze) or signal for being discarded (wasDiscarded).

OK, that makes sense.

 

 

 

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

A web-platform-test for this feature is currently not feasible with the existing infrastructure. The APIs are called when the system decides to transition the Document from one Lifecycle State to another. The new API is triggered on the transition to FROZEN and DISCARDED states. Those transitions cannot be stimulated or forced in a predictive manner. Each vendor can implement their own heuristics on when to transition to those states.

We are working on adding a WebDriver API to freeze and resume a page (issue).

We already added support in chrome’s devtools protocol (Page.setWebLifecycleState), and have the following chromium tests as a first step towards wpt testing.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5644602711212032

--
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/CAK7ODi885Vr5OkcM_DrkLcUdNYSTG2xBKUrRXhS2gihUcPdbcg%40mail.gmail.com.

--

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/CAK7ODi_xW3sFmepRv1SfAHE77zof4fbZxqfCFaWH3si_%3DitJqg%40mail.gmail.com.

[travis....@gmail.com]

 

Edge: Public support

Can you link to support from Edge? Do you know if they intend to follow with an implementation?

Travis was going to write something up, I believe. Otherwise I can link to our discussion (private thread) by forwarding it to a public list :)

Let's wait for Travis' feedback :)

For the public record: our team has looked this over and is comfortable lending our support to this Intent to Ship. We understand that this Intent is scoped to surfacing the events on Mobile only where you already have active interventions, and that this will be an excellent way to gather information on how developers are going to use these events, and whether the processing model works for them, etc. (all good feedback for the spec). One of the only concerns that was brought up was with the handling of beforeunload (which is not strictly impacted by this I2S AFAIK)--years ago, when we tried to implement BFCache, beforeunload handlers gave us a lot of trouble and we "failed candidancy" to enable a B/F cache site if the handler was present. I'm still working to understand and then articulate the specific concerns and what recommendation we'd like to see there, but until we have something more concrete, I don't see that concern as blocking. :-) In general, our team is a big fan, as we would love to enable these events on desktop in Edge where our desktop UWP platform lifecycle (including Edge) is already managed much like Android apps and could benefit greatly from these events--though to be clear, we don't have a plan for implementation on the horizon yet.

[Shubhie Panicker]

Thanks Travis.

Let me clarify what Travis called out regarding surfacing the events on Mobile only and this being a great way to gather information and refine the spec a bit more:

The net effect of shipping the API (in M68) is that when the one existing chrome intervention on mobile after 5mins (for timers & loading) triggers -- then the callback will be fire. 

This improves predictability by providing developers a signal here, and we expect a little bit of usage (not much usage given the expectation on mobile background) and some feedback which would help validate and refine the API *before* we get a lot of usage.

When tab discarding & freezing on desktop ship (initial phase is targeting M69) then we expect a lot of usage, which also means that it would be much harder to change the API after that.

So the trade-off here is that shipping sooner (M68) gives us the opportunity for real world feedback and shipping later (M69) gives us more TAG feedback.

Thoughts?

--

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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ff02b5d3-a129-4066-b4ef-f9ac2a8d5b29%40chromium.org.

[Philip Jägenstedt]

In the Intent to Implement for this, a TAG review request link was included, and there was a review. Like Yoav, I wonder about the changes in between the reviews. Given that Travis has now replied on this thread and he is one of the TAG members, I wonder how much more is likely to come up if we wait. Alex, WDYT?

I've taken a look at the spec, and wonder if https://wicg.github.io/page-lifecycle/spec.html#mod will be upstreamed to the HTML standard. +Domenic Denicola, since your name is on the spec, will you see to it that this happens once the feature has implementation commitments from two vendors? Any whatwg/html tracking issue? (I would worry about monkey patching too, but I see the precise steps to modify are called out.)

For web-platform-tests, as testdriver.js is shaping up and the WebDriver extensions style is established, we will start to consider that part of the expected testing work prior to shipping, but we're not entirely there yet. I saw https://github.com/WICG/page-lifecycle/issues/19 and commented there. I know there is some work ongoing right now, and wonder if this is something you'd like to finish before shipping, or in parallel? My hoped-for end state is that before long, we should be able to point to https://wpt.fyi/results/?label=experimental before shipping, but as mentioned it's not yet reasonable to make it a hard requirement.

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/ff02b5d3-a129-4066-b4ef-f9ac2a8d5b29%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7ODi8ipTJTyt1%2BUQh2Ra_AH3CqACH%2BhTzuBMCaHdprBg%2B0Vw%40mail.gmail.com.

[Fadi Meawad]

On Thu, May 31, 2018 at 2:50 AM Philip Jägenstedt <foo...@google.com> wrote:

In the Intent to Implement for this, a TAG review request link was included, and there was a review. Like Yoav, I wonder about the changes in between the reviews. Given that Travis has now replied on this thread and he is one of the TAG members, I wonder how much more is likely to come up if we wait. Alex, WDYT?

I've taken a look at the spec, and wonder if https://wicg.github.io/page-lifecycle/spec.html#mod will be upstreamed to the HTML standard. +Domenic Denicola, since your name is on the spec, will you see to it that this happens once the feature has implementation commitments from two vendors? Any whatwg/html tracking issue? (I would worry about monkey patching too, but I see the precise steps to modify are called out.)

For web-platform-tests, as testdriver.js is shaping up and the WebDriver extensions style is established, we will start to consider that part of the expected testing work prior to shipping, but we're not entirely there yet. I saw https://github.com/WICG/page-lifecycle/issues/19 and commented there. I know there is some work ongoing right now, and wonder if this is something you'd like to finish before shipping, or in parallel? My hoped-for end state is that before long, we should be able to point to https://wpt.fyi/results/?label=experimental before shipping, but as mentioned it's not yet reasonable to make it a hard requirement.

We are hoping to have a wpt layout test running soon (i.e. a wpt test running as part of blink layout tests). But running it on wpt.fyi might take longer. So ideally having the wpt layout test before shipping while working on the wpt.fyi one in parallel.

[Shubhie Panicker]

On Thu, May 31, 2018 at 8:22 AM, Fadi Meawad <fme...@chromium.org> wrote:

On Thu, May 31, 2018 at 2:50 AM Philip Jägenstedt <foo...@google.com> wrote:

In the Intent to Implement for this, a TAG review request link was included, and there was a review. Like Yoav, I wonder about the changes in between the reviews. Given that Travis has now replied on this thread and he is one of the TAG members, I wonder how much more is likely to come up if we wait. Alex, WDYT?

Since the last TAG review there have been no changes to the API.

During the last TAG review the spec was a very early draft, and since then I have filled it out more in terms of processing model steps.

(Travis, Tobin & their team at Microsoft have looked at the latest spec)

I am working with them on the beforeunload concerns (still waiting to hear the details), however that does not apply at the moment as we are not doing any discarding yet, only freezing on mobile (beforeunload is not relevant for that).

Timeline-wise there are 2 things to note:

1. Desktop tab discarding and freezing is targeted to ship in M69, we definitely need the API at that point (I don't have control on the timeline of this intervention, it is led by desktop org). Ideally we would ship the API one milestone before, but definitely need it for M69. 

2. Once the API ships in M69, it will be difficult to make changes to the API and refine the spec, as we expect non-trivial usage due to the desktop intervention shipping. However, if we ship in M68 then we have an opportunity to refine the API more based on some real world feedback (from mobile freezing), as we won't have much usage due to expectation on mobile.

Given all that, and the fact that I don't expect significant or blocking feedback from 2nd TAG review, I would prefer to ship in M68 but that would need a fast decision on this I2S, and the next TAG meeting would be too late for this (rest my case now :)).

I've taken a look at the spec, and wonder if https://wicg.github.io/page-lifecycle/spec.html#mod will be upstreamed to the HTML standard. +Domenic Denicola, since your name is on the spec, will you see to it that this happens once the feature has implementation commitments from two vendors? Any whatwg/html tracking issue? (I would worry about monkey patching too, but I see the precise steps to modify are called out.)

I am working closely with Domenic on this. 

For web-platform-tests, as testdriver.js is shaping up and the WebDriver extensions style is established, we will start to consider that part of the expected testing work prior to shipping, but we're not entirely there yet. I saw https://github.com/WICG/page-lifecycle/issues/19 and commented there. I know there is some work ongoing right now, and wonder if this is something you'd like to finish before shipping, or in parallel? My hoped-for end state is that before long, we should be able to point to https://wpt.fyi/results/?label=experimental before shipping, but as mentioned it's not yet reasonable to make it a hard requirement.

We are hoping to have a wpt layout test running soon (i.e. a wpt test running as part of blink layout tests). But running it on wpt.fyi might take longer. So ideally having the wpt layout test before shipping while working on the wpt.fyi one in parallel.

+1 

 

On Fri, May 25, 2018 at 10:42 PM Shubhie Panicker <pani...@chromium.org> wrote:

Thanks Travis.

Let me clarify what Travis called out regarding surfacing the events on Mobile only and this being a great way to gather information and refine the spec a bit more:

The net effect of shipping the API (in M68) is that when the one existing chrome intervention on mobile after 5mins (for timers & loading) triggers -- then the callback will be fire. 

This improves predictability by providing developers a signal here, and we expect a little bit of usage (not much usage given the expectation on mobile background) and some feedback which would help validate and refine the API *before* we get a lot of usage.

When tab discarding & freezing on desktop ship (initial phase is targeting M69) then we expect a lot of usage, which also means that it would be much harder to change the API after that.

So the trade-off here is that shipping sooner (M68) gives us the opportunity for real world feedback and shipping later (M69) gives us more TAG feedback.

Thoughts?

On Fri, May 25, 2018 at 12:31 PM, <travis....@gmail.com> wrote:

 

Edge: Public support

Can you link to support from Edge? Do you know if they intend to follow with an implementation?

Travis was going to write something up, I believe. Otherwise I can link to our discussion (private thread) by forwarding it to a public list :)

Let's wait for Travis' feedback :)

For the public record: our team has looked this over and is comfortable lending our support to this Intent to Ship. We understand that this Intent is scoped to surfacing the events on Mobile only where you already have active interventions, and that this will be an excellent way to gather information on how developers are going to use these events, and whether the processing model works for them, etc. (all good feedback for the spec). One of the only concerns that was brought up was with the handling of beforeunload (which is not strictly impacted by this I2S AFAIK)--years ago, when we tried to implement BFCache, beforeunload handlers gave us a lot of trouble and we "failed candidancy" to enable a B/F cache site if the handler was present. I'm still working to understand and then articulate the specific concerns and what recommendation we'd like to see there, but until we have something more concrete, I don't see that concern as blocking. :-) In general, our team is a big fan, as we would love to enable these events on desktop in Edge where our desktop UWP platform lifecycle (including Edge) is already managed much like Android apps and could benefit greatly from these events--though to be clear, we don't have a plan for implementation on the horizon yet.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ff02b5d3-a129-4066-b4ef-f9ac2a8d5b29%40chromium.org.

[sligh...@chromium.org]

Hey all,

On Thursday, May 31, 2018 at 8:48:58 AM UTC-7, Shubhie Panicker wrote:

On Thu, May 31, 2018 at 8:22 AM, Fadi Meawad <fme...@chromium.org> wrote:

On Thu, May 31, 2018 at 2:50 AM Philip Jägenstedt <foo...@google.com> wrote:

In the Intent to Implement for this, a TAG review request link was included, and there was a review. Like Yoav, I wonder about the changes in between the reviews. Given that Travis has now replied on this thread and he is one of the TAG members, I wonder how much more is likely to come up if we wait. Alex, WDYT?

Since the last TAG review there have been no changes to the API.

The proposed I2S is a subset, IIRC.

 

During the last TAG review the spec was a very early draft, and since then I have filled it out more in terms of processing model steps.

(Travis, Tobin & their team at Microsoft have looked at the latest spec)

I am working with them on the beforeunload concerns (still waiting to hear the details), however that does not apply at the moment as we are not doing any discarding yet, only freezing on mobile (beforeunload is not relevant for that).

Timeline-wise there are 2 things to note:

1. Desktop tab discarding and freezing is targeted to ship in M69, we definitely need the API at that point (I don't have control on the timeline of this intervention, it is led by desktop org). Ideally we would ship the API one milestone before, but definitely need it for M69. 

2. Once the API ships in M69, it will be difficult to make changes to the API and refine the spec, as we expect non-trivial usage due to the desktop intervention shipping. However, if we ship in M68 then we have an opportunity to refine the API more based on some real world feedback (from mobile freezing), as we won't have much usage due to expectation on mobile.

Given all that, and the fact that I don't expect significant or blocking feedback from 2nd TAG review, I would prefer to ship in M68 but that would need a fast decision on this I2S, and the next TAG meeting would be too late for this (rest my case now :)).

Per API OWNERS conversation this morning, because this is flagged on for 68, assuming next week's check-in at the TAG call goes well, this will still make 68 (as the flag can be disabled post-branch).

Regards

[Shubhie Panicker]

Friendly ping (post TAG meeting).

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/eec28ad0-6d6f-4ec8-98be-e79f281bb455%40chromium.org.

[Chris Harrelson]

LGTM1

Hey all,

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/ff02b5d3-a129-4066-b4ef-f9ac2a8d5b29%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7ODi8ipTJTyt1%2BUQh2Ra_AH3CqACH%2BhTzuBMCaHdprBg%2B0Vw%40mail.gmail.com.

--
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/eec28ad0-6d6f-4ec8-98be-e79f281bb455%40chromium.org.

--
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/CAK7ODi9s9YZY5Be8iBH1kX7k4s842i7t45UCXw%3DGjnfQct9FHQ%40mail.gmail.com.

[Yoav Weiss]

LGTM 2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-CL4uX2FuM0ZKX03YJQD4UMSjRMEVK7M1%3DWYfho%2B0OhQ%40mail.gmail.com.

[Shubhie Panicker]

On Thu, Jun 7, 2018 at 9:37 PM, Kenneth Rohde Christiansen <kenneth.ch...@gmail.com> wrote:

Hi there,

There has been at least one comment from the TAG team regarding why this is not exposed to the service worker as well. 

Whoops, sorry for missing this, I just updated the issue, copying my response here:

Current thinking on exposing lifecycle state to service worker:

• we intend to expose lifecycle state on WindowClient (similar to visibilityState) in the future. This is needed for supporting background APIs such as ability to update tab title from service worker (eg. inbox count in gmail).
  While currently we don't freeze sites that need to update title or play a sound (eg. chat notification), in the long run we expect to freeze such sites and support their needs via service worker; however this API is currently blocked behind Deferred Push proposal -- a key pre-requisite here.

• we'd expose lifecycle state on WindowClient sooner -- if we find other concrete use-cases / needs.

• service worker is intentionally ephemeral, we don't want to wake up the service worker to inform it about freezing (eg. firing an event like onfreeze) as it undoes much of the performance benefit of freezing -- as service worker itself needs to attach itself to a renderer that is active and not frozen. We could still get some perf wins by improving our implementation here, but this is still undesirable behavior.

 

Cheers

Kenneth

LGTM 2

LGTM1

Hey all,

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ff02b5d3-a129-4066-b4ef-f9ac2a8d5b29%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7ODi8ipTJTyt1%2BUQh2Ra_AH3CqACH%2BhTzuBMCaHdprBg%2B0Vw%40mail.gmail.com.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/eec28ad0-6d6f-4ec8-98be-e79f281bb455%40chromium.org.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7ODi9s9YZY5Be8iBH1kX7k4s842i7t45UCXw%3DGjnfQct9FHQ%40mail.gmail.com.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-CL4uX2FuM0ZKX03YJQD4UMSjRMEVK7M1%3DWYfho%2B0OhQ%40mail.gmail.com.

--

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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhYFWoukvOoOOeFy5kGUiHQG3BRxGitV%2BBC-JtK9LgWrQ%40mail.gmail.com.

[Kenneth Rohde Christiansen]

Hi there,

There has been at least one comment from the TAG team regarding why this is not exposed to the service worker as well. 

Cheers

Kenneth

On Fri, Jun 8, 2018, 6:26 AM Yoav Weiss <yo...@yoav.ws> wrote:

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhYFWoukvOoOOeFy5kGUiHQG3BRxGitV%2BBC-JtK9LgWrQ%40mail.gmail.com.

[Daniel Bratell]

LGTM3

/Daniel

Cheers

Kenneth

LGTM 2

LGTM1

Hey all,

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/ff02b5d3-a129-4066-b4ef-f9ac2a8d5b29%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7ODi8ipTJTyt1%2BUQh2Ra_AH3CqACH%2BhTzuBMCaHdprBg%2B0Vw%40mail.gmail.com.

--
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/eec28ad0-6d6f-4ec8-98be-e79f281bb455%40chromium.org.

--
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/CAK7ODi9s9YZY5Be8iBH1kX7k4s842i7t45UCXw%3DGjnfQct9FHQ%40mail.gmail.com.

--
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/CAOMQ%2Bw-CL4uX2FuM0ZKX03YJQD4UMSjRMEVK7M1%3DWYfho%2B0OhQ%40mail.gmail.com.

--
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/CACj%3DBEhYFWoukvOoOOeFy5kGUiHQG3BRxGitV%2BBC-JtK9LgWrQ%40mail.gmail.com.

--
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/CAK7ODi8R52iXFuMHkyx-ptrX56fzi7uHyTFXFwOV4wQ_MqeVBA%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */