value() can't assert hasValue() because too many places have plausible reasons for calling it on a PropertyDescriptor they basically know nothing about. One such place is CompartmentChecker::check(Handle<JSPropertyDescriptor>). Another is DefinePropertyByDescriptor. Maybe this will change with time.
In some cases we do things like `desc.hasWritable() && desc.writable() != existing_desc.writable()`. It is OK to write it this way, even though we have not checked existing_desc.hasWritable(), because in these cases we already know existingDesc is a complete property descriptor.
CLOSED TREE
Backed out changeset 584d91ffdf88 (bug 1135424)
Backed out changeset d86806ea63f4 (bug 1135424)
Backed out changeset e52401d30a67 (bug 1135424)
The original idea behind the current model was that we wanted ironclad guarantees
that consumers would always get a callback on their promise. But we now have use
cases where the consumer wants to forget about a promise (using the new
Disconnect()) feature, and in some cases wants to shut down the task queue that
the response is going to be dispatched on. In the case of this bug, we want to
avoid waiting for the longest outstanding timer promise to be resolved before
shutting down the MDSM.
So this patch fixes up the pieces needed to make this work:
* Loosening our invariants to allow dispatch targets to be released on any thread,
since MediaTaskQueue and nsIEventTarget both have thread-safe refcounting.
* Releasing mThisVal in Disconnect, so that we no longer depend on successful
dispatch to release it on the correct (dispatch) thread.
* Fiddling with various assertions.
We also make some assertions fatal in nightly/aurora builds while we're at it.
Playback position used in calculating buffering time is set
during metadata reading. This is at end of file for the
video in the bug. As a result the buffering data is always
wrong.
Changed to not setting position during metadata - it is set
during frame playback anyway.
Also changes buffering timeout to 15s from 30s.
Keeping helper classes in Bluetooth's C++ namespace creates collisions
between symbols of different managers' helpers. Moving OPP helpers into
the namespace of |BluetoothOPPManager| fixes this problem for OPP.
Keeping helper classes in Bluetooth's C++ namespace creates collisions
between symbols of different managers' helpers. Moving A2DP helpers into
the namespace of |BluetoothA2dpManager| fixes this problem for A2DP.
Keeping helper classes in Bluetooth's C++ namespace creates collisions
between symbols of different managers' helpers. Moving HFP helpers into
the namespace of |BluetoothHfpManager| fixes this problem for HFP.
