I use fast user switching on my personal OS X machine. I've noticed that Chrome running as an inactive user sometimes chews up lots of CPU. It would be awesome if we could treat this case (running as a user that has been fast-user-switched into inactivity) as some sort of uber-background state -- pause V8 altogether, or at least throttle timers, and that sort of thing.

Here is a scenario that I believe got my machine into a state where 100% of one CPU core was being eaten by a renderer in an inactive user session:

- Open up a single tab and navigate to YouTube
- Go fullscreen
- Pause the video
- Mouse to the upper-right corner of the screen to get to the system user picker and switch to another user account

At this point, the video is still fullscreen in the foreground, but the whole login session is invisible since another user is piloting the machine.

While I've observed this on a Mac, I expect the same thing is possible on Windows, so I'll mark this for both platforms. In Windows-land, WM_WTSSESSION_CHANGE is the message to watch out for. It looks like we do have some plumbing for it, but it's not obvious to me that we use it as a signal that all tabs are suddenly considered backgrounded. Is there a chance that the OS deactivates the active window before sending the session chance message?

Also flagging this as Performance-Power since Chrome is responsible for excessive battery use in this scenario.