PDM::Shutdown() was documented in some implementation as running from the main
thread which wasn't the case. It served no purpose and all can be done from the
destructor instead.
The PDM being a refcounted object can be referenced by more than one object.
Shutting it down too early could cause crash. This is now avoided.
A MediaDataDecoder object can't be used once the PDM that created it is
shutdown.
We ensure that if the PDM is in use by the SharedDecoderManager we do not
shut it down.
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.
--HG--
extra : rebase_source : 68cd15627a62728061e663706cb1ff8c7bb292a0
The Vary header may contain invalid header name values. We should just
ignore such values as opposed to propagating them to the caller. Before
this patch, attempts to add a request with such a Vary header for example
would fail, since the internal QueryCache() call when executing the
CachePutAllAction would fail.
The Vary header may include one or more HTTP header field names, so we
need to extract those names here, similar to the way that the
nsHttpChannel::ResponseWouldVary() function consumes the Vary header.
InternalHeaders::Get() may throw NS_ERROR_TYPE_ERR with an associated message.
The semantics of ErrorResult dictate that the message needs to be consumed by
the time that the object gets destroyed, so we need to clear it before
returning in these two places.