Live data from Hacker News

Chrome will aggressively throttle background tabs

blog.strml.net

61–70 of 403 posts

Re: Chrome will aggressively throttle background tabs

#61

What are we supposed to do about stuff this? Like I wrote a video game https://play.basketball-gm.com/ that lets you open multiple tabs for viewing multiple screens even while simulation is occurring in another tab. But Chrome recently stopped running the simulation if it's in a background tab. Putting my simulation code in a Shared Worker would be nice, except Safari and IE will never support it and it seems likely…

It would be dodgy hack, but another HN comment made reference to a statement that tabs playing audio are always considered "foregrounded": https://groups.google.com/a/chromium.org/forum/#!topic/blink...

Re: Chrome will aggressively throttle background tabs

#63
post #48
post #20

I like the change as a general idea but there obviously needs to be a manual override. Like, I don't want websites to access my camera without permission but obviously I want to allow some websites to do that. A similar permission could be used here and is perfectly backwards compatible: 1. a tab exceeds its quota and throttling kicks in; 2. you visit the tab to check why it stopped working; 3. you get a permission p…

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"

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

Re: Chrome will aggressively throttle background tabs

#64

What are we supposed to do about stuff this? Like I wrote a video game https://play.basketball-gm.com/ that lets you open multiple tabs for viewing multiple screens even while simulation is occurring in another tab. But Chrome recently stopped running the simulation if it's in a background tab. Putting my simulation code in a Shared Worker would be nice, except Safari and IE will never support it and it seems likely…

Could you create a tabbed interface that is just a dumb view of a server state communicated over websockets? Then the user could just open the page in n windows (each on its own tab) and have the same state represented in each?

Problem is, there is no server. All client side. So the tab on which you click "run simulation" is effectively the "server", except it stops running when the user switches tabs.

Re: Chrome will aggressively throttle background tabs

#65
post #48
post #20

I like the change as a general idea but there obviously needs to be a manual override. Like, I don't want websites to access my camera without permission but obviously I want to allow some websites to do that. A similar permission could be used here and is perfectly backwards compatible: 1. a tab exceeds its quota and throttling kicks in; 2. you visit the tab to check why it stopped working; 3. you get a permission p…

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.

Re: Chrome will aggressively throttle background tabs

#66
post #48
post #20

I like the change as a general idea but there obviously needs to be a manual override. Like, I don't want websites to access my camera without permission but obviously I want to allow some websites to do that. A similar permission could be used here and is perfectly backwards compatible: 1. a tab exceeds its quota and throttling kicks in; 2. you visit the tab to check why it stopped working; 3. you get a permission p…

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"

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.

Re: Chrome will aggressively throttle background tabs

#67

Why not have a "this page would like to perform work in the background [allow|block]" notification?

I'd guess it's because most users would have no idea what to choose, would have no idea what the affect of each choice would be, and if you add more text to explain it, most users will not read it. Pop up the notification too often and it becomes a nuisance. Better IMO to bury the choice deep in settings or something, for power users, if you even offer the choice at all.

> I'd guess it's because most users would have no idea what to choose

Sounds like you could kill two birds with one stone: allow a non-lame web and encourage users to learn what that means. We can't complain about tech illiterate users with one corner of the mouth and then make them decide what goes with the other.

> if you add more text to explain it, most users will not read it

They're not users. They're the blight on the back of users. Why cater to them? Is someone who looks left and right before crossing the street a "power pedestrian", too?

"This tab wants to use a lot of [RAM/CPU/GPU] while it is in the background, is that cool with you?

If you don't know what this means, it's best to select no. Fuck that site anyway for using a lot of resources without making it obvious that it's doing something heavy, or asking first, or explaining what is going on. If they don't like users clicking no or even navigating away from the page, that's their problem. If you read this far, click here to claim your Avid Reader Achievement Trophy."

Not bad for a first draft?

Re: Chrome will aggressively throttle background tabs

#68
post #48
post #20

I like the change as a general idea but there obviously needs to be a manual override. Like, I don't want websites to access my camera without permission but obviously I want to allow some websites to do that. A similar permission could be used here and is perfectly backwards compatible: 1. a tab exceeds its quota and throttling kicks in; 2. you visit the tab to check why it stopped working; 3. you get a permission p…

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"

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.

Re: Chrome will aggressively throttle background tabs

#69
post #16

Can't we use serviceWorkers to workaround this? That's what they were created for. I have a webaudio side project that works nicely even on the background using serviceWorkers for timing. I'm hoping it will be the same on 56.

Can you elaborate? What does service workers give you for your web audio project that doesn't work without service works?

I'm curious because I have a HTML5 audio web app that works great, except when running on mobile in the background.

Re: Chrome will aggressively throttle background tabs

#70
post #11

What are we supposed to do about stuff this? Like I wrote a video game https://play.basketball-gm.com/ that lets you open multiple tabs for viewing multiple screens even while simulation is occurring in another tab. But Chrome recently stopped running the simulation if it's in a background tab. Putting my simulation code in a Shared Worker would be nice, except Safari and IE will never support it and it seems likely…

Yes? I mean, you have to admit what you built is the epitome of edge case when it comes to how a browser is typically used, and is actually exactly the type of thing they want to optimize because basically if you aren't looking at the tab, it's not being used (generally). Maybe use electron or something?

I don't think that replacing a traditional desktop app with a web app is an edge case. That's one of the main points of HTML5.
Post reply on HN