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 < [email protected]> 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 > > On Thursday, January 9, 2020 at 11:46:54 PM UTC+5:30 Michaela Merz wrote: > >> 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 >> >> >> >> >> >> On Thu, Jan 9, 2020 at 10:42 AM Daniel Bratell <[email protected]> wrote: >> >>> 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 >>> On 2020-01-04 06:18, [email protected] wrote: >>> >>> 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 >>> >>> >>> >>> >>> On Friday, January 3, 2020 at 1:09:52 PM UTC-6, ตาต้า HHTT wrote: >>>> >>>> เมื่อ วันพฤหัสบดีที่ 23 สิงหาคม ค.ศ. 2018 0 นาฬิกา 26 นาที 32 วินาที >>>> UTC+7, Shubhie Panicker เขียนว่า: >>>> > Contact email >>>> > [email protected] >>>> > >>>> > 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. >>>> >>>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/21e6b190-2339-49a3-a1a2-13a7e625f207%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/21e6b190-2339-49a3-a1a2-13a7e625f207%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >>> > 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 > <https://www.smallcase.com/meta/disclosures> -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALGN1kBKr_HuOJaa0s%2BgfNgxMtS3s6QWo5dt5kp%2BWre5nQ039g%40mail.gmail.com.
