Pinned tabs would be an easy solution for this.

"Don't throttle pinned tabs"

A common use-case is tabs that are streaming music. I'm not sure if most users are even aware of pinned tabs.

They are making an exception for tabs that are playing audio.

You can see the discussion back and forth, here: https://groups.google.com/a/chromium.org/forum/#!topic/blink...

I can see where that will end up though. Everyone who's app was broken by this change will start playing zero volume audio, then the exception will be yanked back.

With the web poised to be the new platform for applications, there really needs to be some more thought put into how to accomplish that goal. The chrome devs already sunset some solutions in that space, like the HTML5 app cache. Now this. Nobody likes a constantly moving target.

No tab should get the audio exception unless it started playing audio while I was looking at it. (reopen yesterdays tabs counts as looking at it...) If you play audio to get around throttling - you should get zero CPU, not just throttled. If you have work to do in the background that is fine - there is legitimate work to do. However once you are playing audio it must mean the other work is done.

What do I know though? I don't normally listen to audio on the web...

I think they are somewhat stuck with conflicting goals. Online games, for example, play audio while doing other work. But it's probably reasonable to pause everything, including the audio, if you move away from the tab.

On the other hand, if they are using Pandora or similar, the end user probably wants the background tab playing and doing other work (showing current album cover art or whatever so it's there if you switch back to that tab).

allow_exception = volume < audible_threshold

Super high pitch noise would get through?

I use pinned tabs extensively and I prefer that they are throttled even more aggressively than standard open tabs. As long as streaming doesn't break.

I have an option set in FF's about:config that disables loading of my pinned tabs on startup, so I regularly keep 200-300 tabs open and only activate the ones I need.

Sometimes it takes weeks to clear my tabs because I barely see a performance hit from having so many open.

Unfortunately this doesn't seem to be the way most users are using pinned tabs. Check out the great suspender. The only tabs it does not freeze are the pinned tabs.

Extending that functionality to throttling seems natural to me.

It looks cool. Browser memory isn't too much of an issue for me because I run NoScript and uMatrix and thus most of the tabs I have open aren't each running an instance of Google Analytics and stuff like that.

It still drives me nuts there's no keyboard shortcut for it. `Command + Shift + P` would be sweeeeeeet.

It is silly to need an extension for this, but I don't know what I would do without `Command + Shift + X`

https://chrome.google.com/webstore/detail/tab-pinner-keyboar...

Awesome. Thanks!

I was not, what a great feature!

didn't they remove pinned tabs a while back, and then re-add them?

While this is elegant, its still dangerous. There are online payments that could check whether your booking is complete in the background by periodically firing ajax calls, bulk updates or uploads, etc.

If those sites are using more than 10% of a CPU to do it, then they've made a catastrophic error, and I'd be glad for Chrome to protect my battery from that.

The business decisions a website makes are none of my business, and if they want to use a polling model for billing because $REASONS then that's their problem.

How is that relevant to throttling?

I don't want to have to pin every single tab I want unthrottled - that's a mixing/piggybacking of otherwise orthogonal concerns. Just make it a separate option I can set per tab.

This would be great. At the very least, I'd like the power to un-throttle a tab myself if I decide to do so - even if there's no prompt, it's important to me that I can let a process run full-speed in the background. Losing that would actually decrease the value of Chrome quite a bit for me.

It could also be a permission granted to a Progressive Web App once the user has decided to install it.

Or just ask for the permission when you first open the page, the same way uber asks for your location.

www.foobar.com wants to:

"Run in the background unthrottled"

The amount of people that will understand what that means is not very substantial. Usually asking for more permissions confuses users as well, people get permission fatigue.

i don't think that would work.

request for location doesn't require the page to explicitly indicate a desire, the request is triggered if the page attempts to use the location services of the JS API. sites that want to run unthrottled can't be identified simply by the usage of a certain API, so the developer would need to add something explicitly to their markup to indicate the desire.

i want control over the feature regardless of whether or not the site's developer deems it appropriate.

I really don't want EVERY website I visit to do this (at least in a pop up).

That's less "backward compatible" than the suggestion to pop up a dialog on switching to the page, because the page needs to know to ask for the permission.

I'm not sure if that's a good thing or a bad thing. After all, backward compatibility is how we got the semantics of an alert() dialog stopping all JS execution.

These days, due to my annoyance with pages reloading themselves when switching to a tab, I'm really not interested in packing more functionality into the whole tab switching mechanism. Like the back button, it should not be visible to web developers.

Every website would start showing such popup. Now (if you have enabled Javascript) many sites show popup to allow notifications the moment you open them. That is annoying when you search for something in Google and have to click "No" for every new page opened.

Seems like the current solution they're advocating for is for sites to do background processing in a [Worker][1].

This seems like a step towards the way things work with mobile apps currently, where the app's main thread gets suspended when its not in the foreground, and background processing happens in separate threads which the user has some degree of control over.

Edit: I meant regular `Worker`s, not `ServiceWorker`s.

[1]: https://developer.mozilla.org/en-US/docs/Web/API/Worker

Except it should probably be web workers that are unthrottled. However, in the current implementation Web workers do get throttled. Service workers are supposed to be for networking and offline applications, not doing cpu related things. As such, service worker lifetimes are really messy since they don't have real guarantees as to if they will randomly restart.

I am having a hard time finding where it states that web workers are treated the same as threads managing visual content. Currently timers in background threads are throttled to 1sec minimum interval however workers are not bound by this constraint. I may just be missing something, but I sure hope not. This would adversely impact many games and applications rendering many of them unusable without the web worker exclusion.

Yeah, sorry. I keep conflating service workers with the larger concept of web workers. For more intensive tasks you'd definitely use a regular dedicated worker, not a service worker.

Far enough down this road, we're just reimplementing 'renice'.

... which may actually be the right solution.

>3.

I swear to god if I see anything mentioning a battery on a desktop machine with no battery...

There's no way to know whether or not it has a battery. Maybe it's on a UPS, for example.

All I know is that my desktop runs at about 70W idle vs. 450W fully-loaded. Unnecessary use of the CPU wastes money regardless of whether or not you're using that money to charge a battery.

Sites can get your battery level from the browser.

IIRC, most of the browsers are going to do away with this functionality soon, however.

Even on a desktop machine, you don't want tabs spinning in the background (using electricity) if you don't need the work being done. That's bad for your wallet and bad for the environment.