Intent to Ship: [Intervention] Freezing task queues in background on mobile

686 views
Skip to first unread message

Shubhie Panicker

unread,
Aug 22, 2018, 1:26:32 PM8/22/18
to blink-dev

Contact email

pani...@chromium.org


Design doc/Spec

Design doc


Summary

Intervention: All freezable task queues in blink scheduler will be frozen (tasks on those queues will not be run) when a renderer has been in the background after grace time of 5 minutes, on Android.

We have been running a Finch experiment over last several months, and more recently on stable. This intent to ramp up and ship it.

The experiment resulted in major (40% to 72%) CPU reduction (and battery saving), and no regressions in regression-metrics.

The intervention is Android only, and inline with expectations on mobile, as mobile platforms already do CPU suspension and throttling in background.


Motivation

Many sites continue activity, even after their app has been in background for over 5 minutes. This consumes non-trivial amount of CPU, battery and network bandwidth, and hurts the responsiveness of the foreground app, especially on mobile. Our UMA data showed non-trivial CPU work being done in background - even after 5 minutes.

Earlier this year we shipped the intervention to freeze loading in background (resulting in significant data saving and some CPU reduction).

This intervention yielded even more significant (~72% in M69) CPU reduction (and battery savings) and shipping it concludes freezing background work on mobile.

(Similar experiments are running on desktop)


Risks

Compatibility & Interoperability

Compat risk: low

Interop risk: low

There are no outstanding issues in the Finch experiment.

Freezing has been made a part of the web platform via Page Lifecycle API, onfreeze and onresume callbacks will notify apps when the “freezing after 5mins” intervention triggers.

(Note that some browsers already do CPU suspension and aggressive throttling in some cases, without firing any callbacks.)


Intervention Guidelines

Predictability

The mechanism is well defined and predictable, same as stopping timers and loading in background. onfreeze / onresume Page Lifecycle callbacks will fire to notify apps. Freezing all freezable task queues improves predictability over freezing only timers & loading.

Avoidability

Continuing to do work in background after 5 minutes is not a good practice, especially on mobile (for data and battery).

Transparency

onfreeze / onresume Page Lifecycle callbacks will fire to notify apps.

Data-driven

See success and regression metrics here.

 

Debuggability

Freezing can be manually triggered and tested via chrome://discards.

A JS callback is emitted when the intervention is triggered.


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

This intervention will be implemented on Android only.

Experiments are ongoing for freezing (and discarding) in background on desktop.


Link to entry on the feature dashboard

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


Requesting approval to ship?

Yes.



Yoav Weiss

unread,
Aug 28, 2018, 7:31:56 AM8/28/18
to Shubhie Panicker, blink-dev
On Wed, Aug 22, 2018 at 7:26 PM Shubhie Panicker <pani...@chromium.org> wrote:

Contact email

pani...@chromium.org


Design doc/Spec

Design doc


Summary

Intervention: All freezable task queues in blink scheduler will be frozen (tasks on those queues will not be run) when a renderer has been in the background after grace time of 5 minutes, on Android.

We have been running a Finch experiment over last several months, and more recently on stable. This intent to ramp up and ship it.

The experiment resulted in major (40% to 72%) CPU reduction (and battery saving), and no regressions in regression-metrics.


Impressive numbers! :)

 

The intervention is Android only, and inline with expectations on mobile, as mobile platforms already do CPU suspension and throttling in background.


Motivation

Many sites continue activity, even after their app has been in background for over 5 minutes. This consumes non-trivial amount of CPU, battery and network bandwidth, and hurts the responsiveness of the foreground app, especially on mobile. Our UMA data showed non-trivial CPU work being done in background - even after 5 minutes.

Earlier this year we shipped the intervention to freeze loading in background (resulting in significant data saving and some CPU reduction).

This intervention yielded even more significant (~72% in M69) CPU reduction (and battery savings) and shipping it concludes freezing background work on mobile.

(Similar experiments are running on desktop)


Risks

Compatibility & Interoperability

Compat risk: low

Interop risk: low

There are no outstanding issues in the Finch experiment.

Freezing has been made a part of the web platform via Page Lifecycle API, onfreeze and onresume callbacks will notify apps when the “freezing after 5mins” intervention triggers.

(Note that some browsers already do CPU suspension and aggressive throttling in some cases, without firing any callbacks.)


Intervention Guidelines

Predictability

The mechanism is well defined and predictable, same as stopping timers and loading in background. onfreeze / onresume Page Lifecycle callbacks will fire to notify apps. Freezing all freezable task queues improves predictability over freezing only timers & loading.

Avoidability

Continuing to do work in background after 5 minutes is not a good practice, especially on mobile (for data and battery).

Transparency

onfreeze / onresume Page Lifecycle callbacks will fire to notify apps.

Data-driven

See success and regression metrics here.


Are the same exclusions applied in the previous intent also applicable here? Do you think the need for user/developer opt-out changes with this intervention?
 

 

Debuggability

Freezing can be manually triggered and tested via chrome://discards.

A JS callback is emitted when the intervention is triggered.


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

This intervention will be implemented on Android only.

Experiments are ongoing for freezing (and discarding) in background on desktop.


Link to entry on the feature dashboard

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


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/CAK7ODi-StMnBPH%3DKJFUtHTVVxe%2BjeJ%3DWp_VZqux4D3v6VrNR9g%40mail.gmail.com.

Shubhie Panicker

unread,
Aug 28, 2018, 3:02:28 PM8/28/18
to Yoav Weiss, blink-dev
Yes the same exclusions apply.
I don't think the need for user/developer opt-outs changes here (compared to freezing loading & timers).
I'd be happy to update our heuristics (exclusions) if we find legitimate breakages, but haven't found anything yet.
The experiment has been running on canary/dev for past 6 months and more recently on beta/stable.
If we find issues during the ramp-up we'll hold off until we fix them.
 
 

 

Debuggability

Freezing can be manually triggered and tested via chrome://discards.

A JS callback is emitted when the intervention is triggered.


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

This intervention will be implemented on Android only.

Experiments are ongoing for freezing (and discarding) in background on desktop.


Link to entry on the feature dashboard

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


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

Shubhie Panicker

unread,
Aug 28, 2018, 6:06:50 PM8/28/18
to Yoav Weiss, blink-dev
On Tue, Aug 28, 2018 at 4:31 AM, Yoav Weiss <yo...@yoav.ws> wrote:



On Wed, Aug 22, 2018 at 7:26 PM Shubhie Panicker <pani...@chromium.org> wrote:

Contact email

pani...@chromium.org


Design doc/Spec

Design doc


Summary

Intervention: All freezable task queues in blink scheduler will be frozen (tasks on those queues will not be run) when a renderer has been in the background after grace time of 5 minutes, on Android.

We have been running a Finch experiment over last several months, and more recently on stable. This intent to ramp up and ship it.

The experiment resulted in major (40% to 72%) CPU reduction (and battery saving), and no regressions in regression-metrics.


Impressive numbers! :)
To clarify - this is our best approximation of renderer CPU usage (not Chrome overall) and specifically the pie representing CPU consumed after 5mins in background.  
 
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Yoav Weiss

unread,
Aug 29, 2018, 8:38:31 AM8/29/18
to Shubhie Panicker, blink-dev
OK. Would be great to document those exclusions so that all related intents can just link to this single place where they are defined. Would it make sense to specify them? Or do we expect them to change over time and between browsers?
 
 
 

 

Debuggability

Freezing can be manually triggered and tested via chrome://discards.

A JS callback is emitted when the intervention is triggered.


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

This intervention will be implemented on Android only.

Experiments are ongoing for freezing (and discarding) in background on desktop.


Link to entry on the feature dashboard

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


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.

Kentaro Hara

unread,
Aug 29, 2018, 5:25:15 PM8/29/18
to Yoav Weiss, Shubhie Panicker, blink-dev
Non-owner LGTM.

Considering 1) our goal of freezing as many tasks on background tabs as possible, 2) the impressive numbers on the CPU reduction and 3) no significant breakage in the past 6 months, this looks like a reasonable intervention to me :)



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


--
Kentaro Hara, Tokyo, Japan

Shubhie Panicker

unread,
Aug 29, 2018, 5:38:48 PM8/29/18
to Yoav Weiss, blink-dev, Chris Hamilton, Philip Walton
Audio is a legitimate exclusion for mobile right now, we have a note in the spec: "NOTE: background tabs that are actively doing work on behalf of the user (eg. playing audio) are generally not frozen or discarded."

Fetch keep-alive should only affect the loading / networking task queue -- I've now added a note here regarding this exception for when networking task queue is freezable. 

The service worker & shared worker exclusions are temporary & implementation-specific:
- service worker should have its own task queue so that we don't have to unfreeze the whole renderer while it's attached to the renderer, captured in this crbug.
- shared worker exclusion should be conditionally applied, captured here; shared worker is not available on mobile anyway.

For desktop, there are a lot more heuristics involved such as webrtc, web-socket, web-usb , as well as things we don't yet have background APIs for: updating title, favicon, chat notification etc.
This is currently captured in this corp only doc, we can make a public version of this doc and link to it in the spec & /web documentation -- would that address your concern? 

 
 
 
 

 

Debuggability

Freezing can be manually triggered and tested via chrome://discards.

A JS callback is emitted when the intervention is triggered.


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

This intervention will be implemented on Android only.

Experiments are ongoing for freezing (and discarding) in background on desktop.


Link to entry on the feature dashboard

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


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+unsubscribe@chromium.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/CACj%3DBEimGk%3DU9ekuSpJcWV8rJYD9Eq%3DYJJ3bkeRvs8cPgpTdLA%40mail.gmail.com.

Yoav Weiss

unread,
Aug 30, 2018, 2:33:24 AM8/30/18
to Shubhie Panicker, blink-dev, Chris Hamilton, Philip Walton
Writing down those exclusions as a public doc and linking to it seems like a good first step.


 
 
 
 

 

Debuggability

Freezing can be manually triggered and tested via chrome://discards.

A JS callback is emitted when the intervention is triggered.


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

This intervention will be implemented on Android only.

Experiments are ongoing for freezing (and discarding) in background on desktop.


I'm missing the "Is this feature fully tested by web-platform-tests?" section.
What's the testing story here?


Link to entry on the feature dashboard

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


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.

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

Shubhie Panicker

unread,
Aug 30, 2018, 8:44:42 PM8/30/18
to Yoav Weiss, blink-dev, Chris Hamilton, Philip Walton
I'm not sure what more we could possibly do, the heuristics should not be standardized -- every browser will use its own heuristics for when they choose to freeze / discard. It is concept of freezing & discarding that are (and can be) standardized.
Though I agree it makes sense to provide the list for the benefit of other interested implementors and developers.



 
 
 
 

 

Debuggability

Freezing can be manually triggered and tested via chrome://discards.

A JS callback is emitted when the intervention is triggered.


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

This intervention will be implemented on Android only.

Experiments are ongoing for freezing (and discarding) in background on desktop.


I'm missing the "Is this feature fully tested by web-platform-tests?" section.
What's the testing story here?
Re: wpt tests, I wasn't sure if that was generally needed for shipping interventions.

In terms of wpt tests for the Page Lifecycle API (separate from this Intent) - we still have
https://github.com/WICG/page-lifecycle/issues/19 which is blocked on infra changes, specifically this one:
foolip@ indicated that the blocker is being prioritized by their team, so we should be able to land once it's done.
 


Link to entry on the feature dashboard

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


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

Yoav Weiss

unread,
Aug 31, 2018, 4:05:17 AM8/31/18
to Shubhie Panicker, blink-dev, Chris Hamilton, Philip Walton
LGTM1

Thanks for writing it down! It's very helpful.

I think it's debatable whether these heuristics should be vendor specific - they are focused on content and user expectations, which shouldn't differ between different engines. At the same time, I agree they'd be very hard to properly specify, and we shouldn't block any work on that.
 



 
 
 
 

 

Debuggability

Freezing can be manually triggered and tested via chrome://discards.

A JS callback is emitted when the intervention is triggered.


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

This intervention will be implemented on Android only.

Experiments are ongoing for freezing (and discarding) in background on desktop.


I'm missing the "Is this feature fully tested by web-platform-tests?" section.
What's the testing story here?
Re: wpt tests, I wasn't sure if that was generally needed for shipping interventions.

In terms of wpt tests for the Page Lifecycle API (separate from this Intent) - we still have
https://github.com/WICG/page-lifecycle/issues/19 which is blocked on infra changes, specifically this one:
foolip@ indicated that the blocker is being prioritized by their team, so we should be able to land once it's done.

Have you considered manual tests in the meantime? They could probably then be converted to regular tests once the API lands.
 
 


Link to entry on the feature dashboard

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


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.

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

Shubhie Panicker

unread,
Aug 31, 2018, 2:56:52 PM8/31/18
to Yoav Weiss, blink-dev, Chris Hamilton, Philip Walton
Thanks for the feedback and LG!

We actually already have automated test coverage with gpu-benchmarking extension:
The thing that is lacking specifically is webdriver support.

BTW, we've spent significant time working on the testing plan (corp-only, but feel free to request access), working with wpt test infra folks and considering all our options etc.
 
 
 


Link to entry on the feature dashboard

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


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

mk...@chromium.org

unread,
Sep 3, 2018, 7:33:27 AM9/3/18
to blink-dev, yo...@yoav.ws, chr...@google.com, philip...@google.com
LGTM2. The performance/battery improvements seem substantial, and the lifecycle callbacks seem to give developers the information they need in order to deal with this intervention. I appreciate the work y'all are doing on the testing front in order to make sure that this kind of thing can be dealt-with in a cross-vendor way in WPT. :)

-mike

Chris Harrelson

unread,
Sep 4, 2018, 12:28:08 PM9/4/18
to Mike West, blink-dev, Yoav Weiss, Chris Hamilton, Philip Walton
Hi Shubhie,

You say "all freezable task queues". Are there any task queues that are not freezable? Is this concept in a spec somewhere if there are differences?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.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.

--
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/91da0334-7781-4331-abb0-31696c489231%40chromium.org.

Shubhie Panicker

unread,
Sep 4, 2018, 5:20:47 PM9/4/18
to Chris Harrelson, Mike West, blink-dev, Yoav Weiss, Chris Hamilton, Philip Walton, Domenic Denicola
On Tue, Sep 4, 2018 at 9:27 AM, Chris Harrelson <chri...@chromium.org> wrote:
Hi Shubhie,

You say "all freezable task queues". Are there any task queues that are not freezable? Is this concept in a spec somewhere if there are differences?
Yes - both in the implementation and the spec there are categories of tasks (task sources in the spec) that are freezable and unfreezable.
Some examples are here:

(+Domenic as FYI)
 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.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.

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

--
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%2Bw90OpRbvcsWs695aNB7QJHzanF%3D-BedVxgOzkw6zrmMGA%40mail.gmail.com.

Chris Harrelson

unread,
Sep 4, 2018, 6:21:37 PM9/4/18
to Shubhie Panicker, Mike West, blink-dev, Yoav Weiss, Chris Hamilton, Philip Walton, Domenic Denicola
Ah great, thanks for that.

LGTM3!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.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.

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

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

--
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/CAK7ODi8sNGy2v-SciNGXYSwCcqXzicpdztynKmvMCMy4qucz%2BA%40mail.gmail.com.

ตาต้า HHTT

unread,
Jan 3, 2020, 2:09:52 PM1/3/20
to blink-dev
เมื่อ วันพฤหัสบดีที่ 23 สิงหาคม ค.ศ. 2018 0 นาฬิกา 26 นาที 32 วินาที UTC+7, Shubhie Panicker เขียนว่า:

roll...@gmail.com

unread,
Jan 4, 2020, 12:18:47 AM1/4/20
to blink-dev
I am fundamentally opposed to any freezing on mobile- and Desktop devices as long as native apps and comparable applications are not treated with the same disregard of the developers intentions. Several web-apps rely on updating the content (such as stock data, messages, measurements) and do not have the same way of being notified in case of data that needs to be updated. While there's web-push, it doesn't allow for silent notifications that would trigger some form of update of the web-app data. In other words, a frozen web-app has no way of being notified (without bothering the user with visible and audible cues) that something important has come up. 

I am also concerned about the apparent disrespect shown to all web-developers by unilaterally deciding to freeze apps thus potentially breaking important functionality as long as there's no viable way to update the data. Freezing should not be happening as long as

a) Periodic background syncing with intervals of not greater than 60 Minutes .. or
b) Silent web-push that can trigger background-syncs ..

.. are implemented. I realize that I am pretty alone in my plead to keep the web-app environment working and healthy. But at least I want to get on the record as somebody who is _strongly_ against any attempt to further skew the environment against web-apps.

Michaela
Message has been deleted

Daniel Bratell

unread,
Jan 9, 2020, 11:42:37 AM1/9/20
to roll...@gmail.com, blink-dev

I think most of your concerns are shared with the people working on this, but they balance it with other concerns as well. If a mobile browser lets too many background tabs run along, they actually end up crashing or getting killed so the current situation is already bad. This is an attempt at making the behaviour well defined and documented.

Maybe the alternative solutions you mention should have come before the intervention but I have confidence that there will at least be something. Because as you say, some sites, acting more as services, do need to be able to work also when they are in the background.

Finally, I expect everyone involved to be responsive to bugs and compatibility problems and either delay or adjust as needed. Nobody wants to break anything useful.

/Daniel

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

Michaela Merz

unread,
Jan 9, 2020, 1:16:54 PM1/9/20
to Daniel Bratell, blink-dev
Thank You Daniel for your answer.  I unfortunately  do not believe that most of my concerns are shared by the people working on that. As a matter of fact, the web and webApp environment has been de-valued a lot over the last year or so. Looking at (audio/video) autoplay, the hiding of notification requests, the refusal to let web-push cut through doze now the freezing of web-pages and apps - all of this makes sense only if one looks at the web as a simple static content development platform. But the web has morphed into much more. Take webRTC as an example: How are we supposed to signal an incoming call when the app has no way of being notified? How are we supposed to keep track on sensor data (like heart rate via webUSB) when the app is frozen? I could append to this list for pages. 

If the (browser-) developer community would really appreciate the web and web-apps as what it has become, it would try to find ways to satisfy the needs of the users and the devices while keeping the fundamental service intact. But they don't. Web services and web-apps are stripped down to ridiculous levels to the point where it just doesn't make any sense anymore.

Now: I can understand Apple's hesitation in regard to the open web. After all, they have a different business model. Mozilla has established some form of well-meaning, enlightened absolutism to please users while some @Google try to push the open-web with new APIs and that's very much appreciated. They are however adding new rooms and extensions to a building that has it's very foundation crumbling.

If freezing becomes the new standard, the web and web-apps as we know it are dead. Sure - you will be able to view ads, other content and videos, but every meaningful interaction will be impossible rendering each and every advanced web-service and web-app impotent.

But the web as a platform was fun while we had it.

Michaela




Michaela Merz

unread,
Oct 13, 2025, 8:01:31 PM (11 hours ago) Oct 13
to Dhawal Keswani, blink-dev, Daniel Bratell
Dhawal - for 5 years or so now, I have been trying to help developers understand how PWAs are de-valued by striping all possible interaction from the core functionalities. autoPlay, webPush, freezing and other methods of providing certain flexibilities are stripped down to very basic levels. It seems that I am fighting the battle (mostly) alone and every other PWA developer is happy with the way things are. Not sure what else I can do to help maintain some interactivity for PWAs as it seems as though the browser folks are  trying to reduce them to static display instruments.  

M.


On Mon, Oct 13, 2025 at 11:44 AM Dhawal Keswani <dhawal....@smallcase.com> wrote:
Hi Folks,

I am extremely disappointed with the decision to rollout Faster background freezing on Android with Chrome 139. While I do understand the motivations, there are legit scenarios which have not been thought through.
For example, this is breaking key finance and banking flows which involve Custom Tabs. 

A web app can launch a new URL (like signing a loan agreement or performing a video KYC session) owned by a bank in a Custom Tab, whereas the background tab waits for a signal for either success or failure. The user activity on the new tab easily takes more than a min, after which the background tab becomes unresponsive to the signals and is unable to put itself back in focus or close the child window, even when it has a reference of it.

If this feature is not supposed to be rolled back, at-least the Custom Tab API on Android should provide a flag to disable it for webapps launched in custom tabs.

Regards,
Dhawal Keswani

This email (including any attachments) may contain confidential, proprietary, privileged and/or private information. The information is intended to be for the use of the individual or entity designated above. If you are not the intended recipient of this message, please notify the sender immediately, and delete the message and any attachments. Any disclosure, reproduction, distribution or other use of this message or any attachments by an individual or entity other than the intended recipient is prohibited. For more detailed information and disclosures, please refer to the Terms and Conditions on our website
Reply all
Reply to author
Forward
0 new messages