John Smith's Blog

Ramblings (mostly) about technical stuff

Detecting if a webpage is running in a background browser tab

Posted by John Smith on

TL;DR version: A hacky way of detecting if a web page is running in a browser tab which isn't currently active. Possibly useful for not autoplaying video or audio. Currently only works in Firefox and Chrome. A rough demo is here.

(This post refers to subject matter covered in more detail in my previous blog post. You don't really need to read that to understand the core of what this post is about though.)

I'm probably very weird in the way I browse, but something that I experience on a more-than-daily basis is:

  1. Go to a site that has a bunch of items/stories/articles, many of which will have links. I'm thinking of things like a Twitter feed, Hacker News, a Gawker Media site, the B3TA newsletter, etc
  2. As I skim down the page, I r-click->open in new tab any items which look interesting and have links. I prefer to do this rather than to hop backwards and forwards between the original page and the linked pages.
  3. Unfortunately, some of those links might be to YouTube or other video services - and this might not be immediately obvious, especially with embedded videos or if URL shorteners are in use. You can then end up with one or more videos starting to autoplay, and you're forced to start going through the tabs to pause the videos until you're ready to watch them.

It struck me that it would be much more user-friendly if videos didn't autoplay if the page was in a window or tab that wasn't currently active or visible. Now, either my webdev and Google skills are deficient (quite possible), or this isn't as easy as you might expect.

Browsers do have focus and blur event triggers, but these don't really help - a page opened in a tab won't fire either of these until the tab is clicked on, and only Firefox fires a focus event when a page loads in an active tab/window.

As far as I can determine, there's no property of the Window object along the lines of 'focusState' that would make all of this dead easy to determine.

I then remembered reading a few posts about requestAnimationFrame, which has been introduced into the latest generation of browsers. The intended use-case for this functionality is to stop browsers burning CPU on animations/game cycles that a user can't actually see or interact with. This seemed like something which would help provide a solution to the problem I was thinking about.

Unforunately, things aren't straightforward. First off, only Firefox and Chrome currently have proper requestAnimationFrame support. Now, there are easy-to-use shims to keep things working on other browsers - unfortunately they do this by just doing the animations as normal on a page in an inactive tab, which doesn't help in my scenario.

Furthermore, the behaviour in the two browsers that do implement it differs - and from a bit of reading, I get the impression that they're not likely to converge to identical implementations. The differences are covered in the previous blog post - suffice to say we need to apply a bit of a fudge-factor to be able to support both browsers.

So, here's an overview of the JavaScript code you'd need to add to a page with video, to make it work in a "civilized manner":

  1. Ensure the video is set to notautoplay
  2. On page load, initialize the following variables:
    • animationCounter = 0
    • stopAnimations = false
    • windowState = undefined
  3. Set up some onFocus() and onBlur() handlers. The handlers will set windowState to "focussed" or "blurred" respectively.
  4. Use requestAnimationFrame an incrementCounter() function. This function - unsurprisingly - increments animationCounter, and if stopAnimations is not true, uses requestAnimationFrame to call itself again
  5. Use setTimeout() to call a determineState() function a second after page load
  6. When determineState() is called, set stopAnimations to true, clear the onFocus() and onBlur() handlers, and do one of the following:
    • If windowState is "unknown"
    • If windowState is "focussed", set the video to autoplay, as the user can definitely see it
    • If windowState is "blurred", don't autoplay the video, as the user definitely can't see it. (I don't believe this state will ever happen, unless the user is juggling between tabs, but it makes sense to cover it for completeness.)
    • If animationCounter is more than 3, the user probably has the page active, so autoplay the video
    • If animationCounter is 2 or less, the user probably has the page inactive, so don't autoplay the video

About this blog

This blog (mostly) covers technology and software development.

Note: I've recently ported the content from my old blog hosted on Google App Engine using some custom code I wrote, to a static site built using Pelican. I've put in place various URL manipulation rules in the webserver config to try to support the old URLs, but it's likely that I've missed some (probably meta ones related to pagination or tagging), so apologies for any 404 errors that you get served.

RSS icon, courtesy of RSS feed for this blog

About the author

I'm a software developer who's worked with a variety of platforms and technologies over the past couple of decades, but for the past 7 or so years I've focussed on web development. Whilst I've always nominally been a "full-stack" developer, I feel more attachment to the back-end side of things.

I'm a web developer for a London-based equities exchange. I've worked at organizations such as News Corporation and Google and BATS Global Markets. Projects I've been involved in have been covered in outlets such as The Guardian, The Telegraph, the Financial Times, The Register and TechCrunch.

Twitter | LinkedIn | GitHub | My CV | Mail

Popular tags

Other sites I've built or been involved with


Most of these have changed quite a bit since my involvement in them...