Safari has been doing something like this since Mavericks. Any idea how it compares?
Reducing power consumption for background tabs
31–40 of 62 posts
Re: Reducing power consumption for background tabs
#32Not super familiar with how the components of iPython/Jupyter notebooks function, so I'll go ahead and ask a potentially stupid question: How might this affect notebooks open in tabs that are running tasks in the background?
Re: Reducing power consumption for background tabs
#33Earlier quoted context omitted.
That would get annoying soon. You won't want your browser to ask for that permission or throttle page layout to use 1% of a single core during page loads or the moment that browser-based shooting game gets lively and requires fast reactions, for example. I think it would be better to give each tab a power budget that, initially, allows it to run for S seconds at full power, and that give it new budget at a rate of x…
Initial page load and rendering should be excluded from any quota. After that the browser should automatically throttle and provide an API to let the web app ask for permission to use more CPU, similar to how geolocation works today. I don't see why this should be too complicated from the user's point of view. We're not talking about hard limits or real time guarantees. Browsers have a lot of wiggle room on the imple…
Define where "initial page load and rendering" ends for a single-page web application. When the DOM becomes stable at the login screen? After the login? The moment the user starts interacting with the page?
Also, how does one control what set of pages a given permission applies to? Exact URL often will be too limited, entire domain too coarse.
Allowing a page to use lots of CPU after every user interaction may be a way out, but if you do that, you don't need the explicit permission system.
[I also think the way browsers handle those geolocation permissions already is too complex for many users. They will simply learn "click 'allow', and things will work; click 'forbid' and things may break"]
Re: Reducing power consumption for background tabs
#34Not super familiar with how the components of iPython/Jupyter notebooks function, so I'll go ahead and ask a potentially stupid question: How might this affect notebooks open in tabs that are running tasks in the background?
Long-running tasks run on the server, not on the client where JS timers matter. You'd get the same results, just maybe a fraction of a second later.
Re: Reducing power consumption for background tabs
#35Not super familiar with how the components of iPython/Jupyter notebooks function, so I'll go ahead and ask a potentially stupid question: How might this affect notebooks open in tabs that are running tasks in the background?
Long-running tasks run on the server, not on the client where JS timers matter. You'd get the same results, just maybe a fraction of a second later.
Ah, I see what you mean. Chrome is throttling client-side operations. Because the python kernel of an iPython notebook is running as server-side code (even if that 'server' is local), it couldn't be subject to throttling by Chrome.
Re: Reducing power consumption for background tabs
#36Earlier quoted context omitted.
There are use cases such as a webmail client still fetching messages so it can notify (e.g. via browser tab icons), or so that a collaborative editor keeps up with changes. Even consider the typical hackernews demo of a javascript genetic algorithm: you probably want to be able to leave it to run for a while while you do other things without being required to keep the tab visible.
Browsers have notification APIs now, from what I've seen. No need to run a full background tab just to handle the occasional notification.
Those notification APIs still get triggered by Javascript running in those tabs. As far as I know, there's no equivalent to the mobile notification APIs where there's a single dedicated socket listening to a central server.
Re: Reducing power consumption for background tabs
#37Not sure if any of you use "okcupid.com", but a single tab of that site will consume 4-5GB of RAM in a matter of an hour. Eventually grinding the entire browser to a halt, and nearly killing the OS in the process. There is a SERIOUS memory issue on that site, and it's always been that way for me. Safari, Chrome, Firefox on a Mac.
I don't use okcupid.com, but gmail, for me, leaks ~4KB per second, even under Chrome 57. Years ago I reported the issue, but it remains unresolved, and I've never received a response. It's not clear to me if it's a gmail issue or a Chrome issue. Either way, leaking 4KB per second is not a good thing. I've only had gmail open for about 2 hours, and it's already using about 325MB of RAM - and there's only 5 messages in my inbox.
Re: Reducing power consumption for background tabs
#38The Great Suspender is a great plugin to achieve this.
This looks nice! As I enabled it, I got the normal warning about "This plugin can view all data" etc, and I started looking for a plugin that can show me what servers plugins are connecting to... it seems there is no such thing. Perhaps time to re-enable little snitch.
For those who don't know: the warning is on any extension that can read and write to the DOM or the page state.
The Great Suspender swaps the entire page out for a placeholder until you re-activate the page.
Re: Reducing power consumption for background tabs
#39The Great Suspender is a great plugin to achieve this.
Nice. I also have blocked JS global in Chrome and activate it on a per site basis.
Re: Reducing power consumption for background tabs
#40From the linked Google doc:
------------------------------------------------------
Suspend all background tabs (~2018) Fully pause a tab in the background after N minutes unless a web developer states that the tab should continue to run via an explicit opt-out.
Remove opt-outs (~2020+) Remove the opt-out and pause all pages. We’ll be able to do this once we’ve (1) ensured that the web platform provides the APIs needed for major use cases and (2) given developers a sufficient deprecation period.
------------------------------------------------------
That sounds a bit scary, and would require a lot of rewriting or refactor existing code. I'm assuming not all the APIs are even ready yet to proactively start doing this already. But sounds like the iOS model, which has it's pros and cons. Probably has a lot of benefits though in the long run.
I hope by pause, means if they switch back it resumes instead of reloading/refreshing. Maybe even emit an event to know it resumed, if the app wants to check if new notifications, etc for it's view... Maybe you were filling out a complex game form - losing state would really be sucky if it reloads, instead of resuming.