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.
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.
We leave the nsIDOMEventTarget* versions fallible for now, but this makes the
common case a lot simpler. Note that this means that pushing a null JSContext,
a bug, is no longer handled at runtime. But I think we should just assert
against it, since there are already callers that don't check the return value.
The goal here is to get rid of this crap entirely, and make nsCxPusher always
push. But that's a scary change, so we do it in chunks. This patch, in particular,
should have zero behavioral change. This means preserving some very wrong behavior.
For instance, currently SafeAutoJSContext never pushes a damn thing, because the
safe JSContext doesn't have an associated nsIScriptContext. We preserve this
behavior, and in fact convert various similarly-buggy consumers to
SafeAutoJSContext, so that we can hoist the behavioral change into a subsequent
patch.
We update the tests to cover this case. There was also a bug in the tests where
we were accidentally testing non-writable Location properties against window
rather than window.location. :-(
We use XPCNativeWrapper.unwrap rather than .wrappedJSObject so that the tests
are agnostic to whether there's an Xray wrapper or not.
I converted test_tree_column_reorder.xul into a chrome test because it does
all sorts of crazy introspection on the binding, and it really should be
a chrome test anyway.
