Earlier quoted context omitted.
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...
Chrome will aggressively throttle background tabs
341–350 of 403 posts
Re: Chrome will aggressively throttle background tabs
#342Earlier quoted context omitted.
If a page signals it's desire to opt-out of aggressive throttling, the user should be notified of this, perhaps by an icon in the tab, so that we can either close it or force the throttling. I'm a laptop user and CPU-hungry background tabs are a huge drain on my battery life. If something is opting out of or otherwise excluded from throttling, I want to know about it. Thanks.
Icon: "speaker" for audio sites, icon: "Power cable" for background power usage?
Re: Chrome will aggressively throttle background tabs
#343Earlier quoted context omitted.
Bingo. The user ultimately needs to retain control. And I'm especially interested in the exception for audio - that really should be user-controllable, otherwise it just encourages annoying page authors to be even more annoying.
The audio thing works because there is an obvious icon in the tab bar that shows the source of audio, so if developers use it in an annoying way the user can easily respond appropriately.
Re: Chrome will aggressively throttle background tabs
#344Earlier quoted context omitted.
>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.
IIRC, most of the browsers are going to do away with this functionality soon, however.
Re: Chrome will aggressively throttle background tabs
#345What 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
#346Earlier quoted context omitted.
No: the Chrome task manager shows activity per process, not per tab; processes typically have many many tabs lumped together (which undermines the security advantage, particularly as commonly-opened tabs like e-mail tend to end up having at least one instance open in every single process). You can't use this feature to figure out which tabs are using CPU unless you are barely using the web browser in the first place.
Whether or not tabs are in a new process depends on how it was opened. For example, opening a new tab with a control-click or middle-click will result in the new tab share a process with the original, however, right-clicking and selecting "Open in new tab" will result in the new tab having its own process.
Realistically, you just can't use the Chrome task manager to find slow tabs :/. I'd argue that Firefox's recent work in about:performance is actually more useful for this purpose (though isn't very good at dealing with large numbers of tabs that are each using only a small amount of CPU; the real solution to that, though, should just be tab suspension).
Re: Chrome will aggressively throttle background tabs
#347I run a real time charting platform for Bitcoin traders (like those using BitMEX) and the app does a lot of updating/refreshing. I recently learned of the visibilitychange API and managed to make huge improvements in the app's performance when running in the background - on the order of ~75% reduction in CPU usage when running in the background. [1] var doVisualUpdates = true; document.addEventListener('visibilitycha…
Why should the browser rely on the webpage developer to tell it to not redraw things in a tab that isn't the visible one? The browser by default shouldn't redraw content in a tab that isn't visible. This seems like the most obvious thing in the world.
Re: Chrome will aggressively throttle background tabs
#348A simple, trivial feature that's in every browser on Earth, except bloody Chrome.
Its been requested pretty much forever and Chrome takes a perverse delight in ignoring the most requested features, because of course they know better than their users.
other examples - multi row tabs, customizable fonts, and actually giving a damn about memory usage.
Chrome is a memory hog and instead of optimizing that, the solution is to kill background tabs. This is very similar to Android's logic - instead of trying to fix rampant 'Android system' and 'Play services' wakelocks which cause massive battery drain, the fix was to forcefully suspend apps via Doze, which of course ignores the real problem entirely.
Re: Chrome will aggressively throttle background tabs
#349Earlier quoted context omitted.
It is a pure SPA, you just have the option of opening multiple instances at the same time. Like I can open gmail in two tabs, but it's still an SPA. And yeah tabs in JS are possible and I might go down that route, it'll just be a lot of extra work to replicate a UI that already exists fine.
Here's an example: http://orteil.dashnet.org/cookieclicker/ Opening another tab creates a new bakery, not a view into the same bakery. (This only works if you haven't played before or clear your cookies.) Edit: If you really want to keep the same functionality then you would need to bring server communication into the mix. It's possible to either run the simulation server-side, or at least communicate the state betwe…