Perhaps ugh I hate even suggesting this, a nag bar could pop up when the user navigates back to the tab to inform them that the site was aggressively throttled.Īnyhow, I am glad you guys are getting out ahead of this, I think this stuff is going to get worse as sites seek to run more code on our machines in ways we cannot easily discern. And hopefully for legacy sites that won't be updated, the visual indicators above will clue users in as to fact that the browser is throttling the site. Perhaps a unthrottled-background permission request API can be done. I would figure that for larger more public facing devs, the experience might be a bit more tedious. They are mostly in house tools so as long as I can instruct users to override the throttle, provided I am given that option, which it seems like I will be. So I am fine with this being the default option even though it will break apps I have written. (A lot of this would be almost trivial by showing little cpu use bars, with a line where the throttle is, but it might look kind of ugly)Įven though this is going to break some of my apps, I can see a greater good here, and I am 100% for helping out with battery life, and preventing my machine from being some sort of ad network computation shard. * The ability via `site settings` to disable the throttling, however if a site is using excessive background resources, some sort of ui should show indicate such. Tab has throttling disabled by user-request. * A Visual Indicator on the tab, similar in spirit to the speaker or red recording circle, that conveysĢ. So to that end, communicating what's going on to the users, is I think pretty important so hopefully: However a lot of times they don't even know that it is and, surprise! the battery is drained, or everything is running slow and it's time to press shift+esc and stare at the jumping percentages in the task manager. If the user wants the site to run in the background, great. To me the fundamental issue is one of user control. To me `site settings` `Throttle this site when in the background, Warning: this may slow your machine and consume additional battery resources` (Maybe pinned will enlarge if document.title is changed or something don't know never use it). I use the text on there to communicate alerts / information to users. Pinning a tab has the side-effect of shrinking its title bar to just the icon. I'd love to reverse this and punish tabs that play audio in the background! (or to allow for genuinely useful uses, such as message alerts, punish those that play more then 5 seconds of audio in a minute, unless tey are whitelisted).
> Tabs playing audio are already unthrottled
How is "active" defined here? I foresee advertisers opening a websocket that does as little as possible in order to get a prompt-less lifting of the throttle. > disable aggressive throttling when active websocket connection is present. so if there is an opt out I expect it to be abused such that this pain point will not go away.Īs well as asking if a particular domain should be allowed to unthrottle itself as others have suggested (or instead of if there is a fear that extra UI interactions will confuse the user) perhaps you could only allow it if the top level frame also opts out? This would give control back to the main page maintainer and if used in combination with the prompts could confuse less technical users less (the request for unthrottling comes from a recognised name like not .com) and sometimes are two notable offenders here in my experience.Īdvertisers will opt of anything that might throttle their content whether they need to or not, without testing if they need to, just in case. The main problems I have with background tabs and resource use is advertising iframes on otherwise inert pages. > We will also consider more signals to use in exempting a page from this throttling 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). Realistically, you just can't use the Chrome task manager to find slow tabs :/.
#Iflscience tab suspender windows
I know this, and have even complained about it in the past to Chrome engineers (as it allows an attacker way too much control over getting security sensitive tabs into the same process, further weakening the way overstated security benefits of having separate renderer processes, which is often muddled together with the actual/real benefit of separating processes by capability, as with rendering, networking, windowing, plugins, etc.), but there is also a limited number of processes: as I believe the default is 35, if you have more than 35 tabs open across all windows you are guaranteed to have some tabs sharing a process (by pidgeon hole principle).
0 kommentar(er)
