Taras recently blogged on how websites manage to ruin Firefox performance by continuing to do something even though their tab is no longer active — they keep updating the view that you cannot see. He wondered whether it would be possible to suspend these tabs from an extension. I looked into this and there is a way to suspend all timeouts for a tab — something that an extension could use. Getting the details right wasn’t quite trivial but I think that my extension gets it right now: Suspend background tabs. Enjoy!
This doesn’t completely disable all activity in the background tabs of course. Network requests will continue, videos will also keep playing. So I might implement some improvements in future. However, please have understanding that this is a very low priority side-project for me. So it’s best if you bring your code. The current code is here.
Only one more thing would be great:
option to whitelist a site (like twitter).
If I understand Taras correctly, Twitter is one of the worst offenders :)
Anyway, this is currently possible if you pin the tab – there is a “Don’t suspend pinned app tabs” option.
Seems not compatible with Firefox 14? Not even with Nightly Tester Tools installed?
I would greatly appreciate your help!
What do you mean? From all I know, it works perfectly fine with Firefox 14. You don’t need Nightly Tester Tools – it is explicitly marked as compatible.
I’m sorry but, in mobile Aurora or Nightly too?
No, only desktop Firefox is currently supported. Adding support for Aurora Mobile shouldn’t be hard but so far I didn’t have time for that.
Works great on Firefox 12 so far. Thanks!
Ah, ok! Many thanks for all your quick replies! I’ll be looking forward to the mobile version then!
I find it astounding that for so long browser vendors seemingly gave zero consideration to the scalability of tabbed browsing. Now it’s as if everyone’s giving up on tabbed browsing altogether. Why shouldn’t a website keep updating itself in the background? All these web evangelists keep rabbiting on about the web – generally compared to native apps on mobile and/or plugins – and keep building all these real-time and ‘one-page’-supporting protocols such as WebRTC, AJAX, WebSockets and so forth, yet now they’re all complaining when web developers use them! Hypocrisy!!!
A web developer is not immoral if they run code that will update their site so that it is current immediately upon the user clicking back to it.
I suggest that the evangelists may finally have pushed the boundaries too far. Why was your average Flash site a performance hog? Perhaps because Flash allowed developers to do a lot of what HTML5 is trying to mimic? Therefore doesn’t a simplistic analysis suggest that getting rid of Flash solves the proprietary issues with it, but adding Flash’s functionality to HTML5 would just add the performance degradation as well? That appears to be what is happening. From complaining about background loading to converting tabs to delay-load (making them glorified bookmarks), despite all the hype about the JS engine race and delivery of HTML5 features, browsers are simply hitting a very hard performance road block.
Has anyone stopped to think that now we see much less Flash sites but that plugin we’ve been blaming for all sorts of evils is slowly disappearing yet performance degradation in web browsers still exists.
Please bear with me for the loads of incoming questions, but I would be very much interested in the details of this extension, on what exactly it now suspends/throttles/whatnot…
So what activity is now disabled? I guess calls by setTimeout/setInterval are suspended (which were already throttled in newer Firefox versions, see bug 379535)? Meta-refresh probably too (like NoScript does per-default for untrusted sites)? Stuff that depends on the Firefox core is probably not touched, like animated images (bug 588975), incremental layout (bug 341046), prioritisation of network requests (would no NO_DELAY for background tabs make sense?), suspension of the text blinking timer in background tabs (bug 526715), or some of the other stuff that blocks bug 595574?
With videos you mean plugin-based and/or HTML5?
How is it determined that a background tab is a background tab? Whether it is an “active” tab? What about the topmost tab in a minimized window?
Yes, setTimeout/setInterval calls are completely suspended – they will only fire once you go back to that tab. Also, animations via @mozRequestAnimationFrame@ are suspended. As to meta refresh – not sure, probably not, this needs to be checked. Everything else currently stays active and would need additional code (with videos I mean both plugin-based and HTML5).
A background tab is one that isn’t visible inside its window. I don’t know a good way to determine whether a window is visible so invisible windows aren’t being handled.
Thanks for the replies.
Concerning background tabs: There has be at least some internal definition of what an active or inactive tab is somewhere, see for example the fixed bug 648045 (“Mark the active tab in minimized windows as inactive”): https://bugzil.la/648045
It’s essentially a special handling for minimized windows (via listening to @sizemodechange@ event). I can implement a similar logic, simply reusing the logic currently used by @tabbrowser@ doesn’t seem possible.
Sites such as turbobit.net makes the user wait for a 60 second countdown before user can download a file. In such a scenario it would improve productivity if the user can browse other tabs while backgroundtab resumes countdown.
I think whitelisting is a more user convenient approach than pinning tabs.
nice extension, mostly works well. one problem and a possible solution:
some sites don’t open well in background tabs. for example, try to middle-click open this business week page in the background, it breaks:
(it breaks only the first time, if you don’t have the site cached i guess. if it doesn’t happen, try a clean profile)
the possible solution might be to give every new tab a “grace period” for say 5 seconds where you don’t block events. after that, if they don’t load, it’s theirs fault.. ;)
just discovered another bug to report that might be fixed by the previous suggestion (5 second grace period for new tabs):
@tom jones: Have you tried the built-in Flash blocking in NoScript?
I remember encountering incompatibilities between FlashBlock and NoScript because FlashBlock hooked its “click to play” code up as part of the page rather than part of the browser and it’d be interesting to see if this interferes with NoScript’s flash blocking, given that it’s supposed to be not only immune to that problem but also secure protection against 0-day Flash exploits.
You should really implement a white list, some specific sites require background loading.
I’m of two minds about this extension. OT1H it sounds like a nice way to avoid, let’s say, Facebook and Gmail, or maybe forever-animated GIFs, grabbing CPU cycles to update tabs in which I’m not interested at the moment; OTOH won’t it prevent my multitab homepage from loading immediately at startup, without waiting for me to look at each and every tab?
It won’t. As I said in the blog post, network activity is currently unaffected by this extension. This might change in future, then we will have to figure out something to avoid situations like the one you mention.
Have been using this and it’s really helpful in managing the expense of the browser on the CPU. One thing I will save though is that if it could wait till any background activity has stopped before suspending it, that’d be good. i.e. clicking post on a form.
BTW, any chance of a blog post detailing your progress regarding making ABP restartless?