Bug 835563 - When an iframe mozbrowser's embedder calls setVisible(false), immediately send the relevant process into the background (if none of its other frames are in the foreground). r=cjones
Bug 840277 - Explicitly check that the preallocated process hasn't been killed before we use it. r=cjones

We have to do this check /after/ we set the process's priority, since
before then, it has BACKGROUND priority and is a candidate for killing.
Bug 836654 - Part 0: Add constants CONTENT_PROCESS_{UNKNOWN_ID,MAIN_ID} to HalTypes.h and remove the equivalent constants from ContentParent.h. r=cjones
Bug 836654 - Part 1: Don't require the "power" permission to do GetWakeLockInfo from a child process. r=cjones
Bug 836654 - Part 2: Add PROCESS_PRIORITY_FOREGROUND_HIGH. r=cjones
Bug 836654 - Part 3: Modify hal to accept a ContentParent ID in ModifyWakeLock(). r=cjones

Also return the list of processes holding the lock in GetWakeLockInfo
and in the wake-lock changed notification.
Bug 836654 - Part 4: Add PowerManagerService::NewWakeLockOnBehalfOfProcess. r=cjones
Bug 836654 - Part 5: Add nsIMozBrowserFrame::isExpectingSystemMessage. r=bz
Bug 836654 - Part 6: If a process is "critical" and holds the "cpu" or "high-priority" wake lock, give it priority FOREGROUND_HIGH. r=cjones
Bug 836654 - Part 7: Hold a CPU wake lock while a "critical" process that's expecting a system message loads. r=cjones,fabrice
Bug 836654 - Part 8: Inform the mozbrowser embedder when we're opening a frame that we expect to send a system message to. r=cjones
Bug 836654 - Part 9: During app-frame creation, take the CPU wake lock only after sending down the mozapptype. r=cjones

This prevents the child process from downgrading its CPU priority when
it notices that it has the CPU wake lock but no "critical" frames.

In this patch we also reduce the scope of a race condition which occurs
when we don't launch a new process for an app.  In this case, we still
need to set the child process's priority and then check that the process
is still alive.

Because this isn't a brand-new process, it's possible that the process
will downgrade its priority (e.g. due to a timer) after we check that
it's still alive and before it notices that we've acquired the CPU wake
lock on its behalf.  This patch does not resolve that race.
Bug 836654 - Part 10: Don't acquire the CPU wake lock in the alarm service any longer. r=cjones

We've removed the event that the AlarmService was listening to in order
to find out when we could drop the lock!
Bug 836654 - Part 11: Touch the CLOBBER file, because something here seems to be causing the IndexedDB tests to fail.