| Pinning a tab has the side-effect of shrinking its title bar to just the icon. I use the text on there to communicate alerts / information to users. (Maybe pinned will enlarge if document.title is changed or something don't know never use it). So hopefully there is another way. To me `site settings` `Throttle this site when in the background, Warning: this may slow your machine and consume additional battery resources` To me the fundamental issue is one of user control. If the user wants the site to run in the background, great. 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. So to that end, communicating what's going on to the users, is I think pretty important so hopefully: * A Visual Indicator on the tab, similar in spirit to the speaker or red recording circle, that conveys 1. Tab is fully utilizing its throttle.
2. Tab has throttling disabled by user-request.
And then to give users control:* 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. (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) Even 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. So I am fine with this being the default option even though it will break apps I have written. 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. I would figure that for larger more public facing devs, the experience might be a bit more tedious. Perhaps a unthrottled-background permission request API can be done. 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 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. Anyhow, 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. So I actually don't like that workers / websockets / audio work around aggressive throttling, because the bad actors are just going to use that to burn cpu in the background without the users consent. Hopefully if executed well, with a helpful ui, this can be used to stop any unwanted and often unseen but still felt cpu waste while allowing sites the user actually does rely on to continue working. ps, I'll cross post this to your tracker as well as you requested, I just know that leaving it here will get more eyeballs from a larger community to give their feedback as well. |