Currently when sending a beacon, HttpBaseChannel::ShouldIntercept tries
to get access to the nsINetworkInterceptController interface through the
channel's notification callbacks, but in this case the notification
callback is the nsCORSListenerProxy object (thanks to
nsCORSListenerProxy::Init).
nsCORSListenerProxy already knows how to forward calls to
nsIInterfaceRequestor::GetInterface to mOuterNotificationCallbacks, and
ShouldIntercept calls GetInterfce. But mOuterNotificationCallbacks is
set by default to the callbacks of the channel at the time
nsCORSListenerProxy is called, and the callbacks on this channel is
intentionally null, so ShouldIntercept bails out and the beacon never
gets intercepted.
This patch extends nsCORSListenerProxy to make it aware of
nsINetworkInterceptController, and have it route the request for
nsINetworkInterceptController correctly to the docshell without the need
to mess with the notification callbacks.
This will be tested in bug 1147699.
These methods will soon be used to start animations that are waiting to start
and also to finish pausing animations that are waiting to pause. As a result
we rename them to TriggerXXX since that's a bit more generic.
There are still references to StartXXX within PendingPlayerTracker. These will
be updated in a subsequent patch once we have the appropriate methods available
on AnimationPlayer to call.
Also: Change signature of these functions and methods to all have the same arguments in the same order: (cx, obj, id, v, receiver). Also change v from MutableHandleValue to HandleValue.
There is no change in behavior.
In fact the new error message `JSMSG_SET_NON_OBJECT_RECEIVER` is
impossible to trigger from scripts for now, I think (after re-reading
the whole patch with this in mind). JS_ForwardSetPropertyTo is the only
way to get a non-object receiver into the engine, but no caller
currently does so.
We're installing new pipes here, and they should work, but for now it's
the same cold water flowing through as before. Actually hooking up the
hot water is left for another bug (one with tests, not to put too fine a
point on it).
Notes:
* InvokeGetterOrSetter had to be split into two functions:
InvokeGetter takes a MutableHandleValue out-param,
InvokeSetter a HandleValue in-param.
* Watchpoints can still tamper with values being assigned. So can
JSSetterOps. I'm pleased we can support this craziness in a way that
doesn't have to spread via the type system to encompass the entire
codebase.
* Change in GlobalObject::setIntrinsicValue is not really a change.
Yes, it asserted before, but an exception thrown during self-hosting
initialization is not going to go unnoticed either.
* Since the receiver argument to js::SetProperty() is at the end now, it
makes sense for it to be optional. Some callers look nicer.
Also: Change signature of these functions and methods to all have the same arguments in the same order: (cx, obj, id, v, receiver). Also change v from MutableHandleValue to HandleValue.
There is no change in behavior.
In fact the new error message `JSMSG_SET_NON_OBJECT_RECEIVER` is
impossible to trigger from scripts for now, I think (after re-reading
the whole patch with this in mind). JS_ForwardSetPropertyTo is the only
way to get a non-object receiver into the engine, but no caller
currently does so.
We're installing new pipes here, and they should work, but for now it's
the same cold water flowing through as before. Actually hooking up the
hot water is left for another bug (one with tests, not to put too fine a
point on it).
Notes:
* InvokeGetterOrSetter had to be split into two functions:
InvokeGetter takes a MutableHandleValue out-param,
InvokeSetter a HandleValue in-param.
* Watchpoints can still tamper with values being assigned. So can
JSSetterOps. I'm pleased we can support this craziness in a way that
doesn't have to spread via the type system to encompass the entire
codebase.
* Change in GlobalObject::setIntrinsicValue is not really a change.
Yes, it asserted before, but an exception thrown during self-hosting
initialization is not going to go unnoticed either.
* Since the receiver argument to js::SetProperty() is at the end now, it
makes sense for it to be optional. Some callers look nicer.
Note that this is not a behavior change in the aRunInGlobalScope case in
nsFrameMessageManager, because that case never does setCompileAndGo(true) anyway.
