Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome will aggressively throttle background tabs

blog.strml.net

Post reply on HN
Print view View original

301–310 of 403 posts

Re: Chrome will aggressively throttle background tabs

#301

Post by overcast »

cookiecaper wrote: post #287
mikeash wrote: post #161

Earlier quoted context omitted.

Why is it that whenever somebody has a problem that less than 100% of people experience, the response is always "you must be doing it wrong" rather than "I must be lucky"?

Because the quantity isn't just less than 100%, it's a small minority. Chrome and Firefox are among the most widely-used pieces of software in the world. I'm not saying they don't have weird bugs, but they don't crash daily for most users. While the OP may not be doing anything "wrong", he is almost definitely doing something unusual, or has deeper issues like malware or malfunctioning hardware. If the ratio were inv…

I would suspect a majority of the world does not keep dozens of tabs open, on an computer that never shuts down. You have to remember which forum you're on here. Any software issue, usually rears its head relatively quickly from one of our machines around here.

Re: Chrome will aggressively throttle background tabs

#302

Post by cpeterso »

STRML wrote: post #279
LeanderK wrote: post #276

Earlier quoted context omitted.

i don't know anything about React, but why can't react itself try to manage this?

React is in the business of limiting its API surface, not increasing it. I think they have done a great job of it - libraries like this should exist in userland.

It seems like React could listen for visibilitychange itself to throttle its own events or virtual DOM processing. It wouldn't necessarily need to expose visibilitychange as a library API.

Re: Chrome will aggressively throttle background tabs

#303

Post by sirclueless »

ben174 wrote: post #288
BinaryIdiot wrote: post #284

Earlier quoted context omitted.

While I agree with you in theory , this will only help a small fraction of us techie users. The average user is going to see a new, weird icon on their eBay Auction tab and call their computer company to ask them what it is and if they're being hacked. When I did support for Apple Care, every single update if it had new or extra icons we always got lots of calls like this.

I'm sure some good UX could alleviate this. Maybe a spinning gear icon? Maybe a battery draining animation? Something to signify, 'this tab is doing some heavy lifting right now'.

It's actually a pretty rational response for someone who is only moderately aware of what is going on in their computer. If they are aware that malware and adware can cause unwanted changes on their computer, perhaps because they've been bitten before, then a new icon -- even one that is easily interpreted (which this one would not be) -- looks scary.

Re: Chrome will aggressively throttle background tabs

#304

Post by onion2k »

PetahNZ wrote: post #139
onion2k wrote: post #112

Earlier quoted context omitted.

As a developer you need to decide whether or not to support a browser, and if that browser doesn't provide the APIs you need then you should drop support for that feature in that browser. In this case, if Chrome is making a change that you can't or won't change your game for then the solution is to detect Chrome and display a "This game only works in a single tab in Chrome. Try Firefox!" message if a user opens it in…

It's your customers that generally dictate what browser you support.

Some people are in the fortunate position where they can choose to ignore large sections of their potential customer base. Someone who writes a game as (presumably) a side project is in exactly that position.

Re: Chrome will aggressively throttle background tabs

#305

Post by Spoom »

croddin wrote: post #72
Spoom wrote: post #56

Earlier quoted context omitted.

I don't believe it will. From https://groups.google.com/a/chromium.org/forum/#!topic/blink... : Background tabs usually do not have a visible impact for user (tabs with audio are always considered foregrounded).

Is that a workaround/loophole then? A tab can play silent or very quiet audio and then run unthrottled?

One of the first comments on the link above mentions this as a potential exploit; they said they would watch for people attempting it and attempt to mitigate it if it becomes popular.

Re: Chrome will aggressively throttle background tabs

#306

Post by steego »

BinaryIdiot wrote: post #286
steego wrote: post #272

Personally speaking (That means I'm speaking for myself), I could absolutely care less about the plight of the developer who wants their page to run stuff in the background. If you really think I should be running something in the background, you should ask Chrome for that permission so Chrome can ask me. If I say yes, then feel free, but no website should have this for free.

> no website should have this for free. Why not? Your applications on the desktop can run background tasks without your approval. Your phone's applications on iOS and Android can run background tasks without your approval. The web has tons of web applications some of which more complex than stand alone apps. So why wouldn't they be afforded the same? Asking would be a bit of a UX nightmare. You'll have so few users e…

Have you figured out the difference between webpages and apps yet? Let me know when you do and we can continue this discussion.

FYI, I switched to iOS because they're much more aggressive controlling about runaway background processes.

Re: Chrome will aggressively throttle background tabs

#307

Post by flukus »

brandon272 wrote: post #25
overcast wrote: post #5

Can we aggressively throttle memory usage? Why does it require 300-500MB of ram PER TAB?

Does Chrome only use RAM if it thinks it is available? (i.e. if it starts detecting that other process are running and eating up RAM, will it use less?)

Firefox on Linux used to many years ago, it even included swap space as available memory.

Re: Chrome will aggressively throttle background tabs

#308

Post by flukus »

BinaryIdiot wrote: post #286
steego wrote: post #272

Personally speaking (That means I'm speaking for myself), I could absolutely care less about the plight of the developer who wants their page to run stuff in the background. If you really think I should be running something in the background, you should ask Chrome for that permission so Chrome can ask me. If I say yes, then feel free, but no website should have this for free.

> no website should have this for free. Why not? Your applications on the desktop can run background tasks without your approval. Your phone's applications on iOS and Android can run background tasks without your approval. The web has tons of web applications some of which more complex than stand alone apps. So why wouldn't they be afforded the same? Asking would be a bit of a UX nightmare. You'll have so few users e…

They aren't treated the same because web apps are a lot more resource intensive than their desktop counter parts.

Re: Chrome will aggressively throttle background tabs

#309

Post by flukus »

dingo_bat wrote: post #182

Why though? I run Chrome on my decently powered laptop and most of the time I am connected to AC power. I want the machine to run as close to full potential as possible. This is not a mobile phone that needs to preserve battery by killing every background process. It's frustrating because no other browser matches chrome in smoothness and bug-free-ness, so I have no option but to tolerate the trademark anti-user behav…

If you want the machine to run close to it's full potential you should be steering well clear of web apps.

Re: Chrome will aggressively throttle background tabs

#310

Post by tropo »

altimin wrote: post #176

Hi, this is Alexander. I'm an engineer on Chromium team working on scheduling and on background tab throttling in particular. Firstly, I want to make clear that we are not shipping this in Chrome 56. We have enabled throttling as an experiment in beta channel to measure impact and collect feedback from web devs. We will aim to ship it in Chrome 57, subject to further feedback. In response to concerns voiced we will d…

Speaking of audio tabs, the mute setting should be inherited. If I have a muted tab and then open a link in a new tab, I should get a muted tab.
Post reply on HN