CallTypedArrayMethodIfWrapped (and the CallNonGeneric machinery throughout the
engine) unwraps the `this` argument, but the other arguments are only rewrapped
for the target compartment.
The pattern being used before this patch to get the length of a TypedArray or
possible TypedArray wrapper is:
`callFunction(CallTypedArrayMethodIfWrapped, O, O, "TypedArrayLength")`
The first `O` is the `this` value and the second is an argument. If `O` is a
cross-compartment wrapper, this works fine. The first `O` is unwrapped, revealing
the actual TypedArray object; the second `O` is rewrapped for that TypedArray's
compartment, producing the same TypedArray.
However, if `O` is a same-compartment wrapper, this doesn't work. The first `O` is
unwrapped, revealing the actual TypedArray object in the same compartment;
rewrapping the other `O` does nothing to it, since it is already an object in the
target compartment. Thus TypedArrayLength receives a `this` value that's an
unwrapped TypedArray, but an argument that is still a wrapper.
The fix is to have CallTypedArrayMethodIfWrapped targets only expect `this`
to be an unwrapped TypedArray.
Usually, mShouldFallbackIfError has been reset to false in DataCallback()
before Stop() is called. However, if fallback to a system clock driver due to
cubeb error had already occurred, then mShouldFallbackIfError would not have
been reset, and Stop() is still called. With mShouldFallbackIfError still
true, a cubeb error in stop would have created another fallback thread.
I expect that resetting mShouldFallbackIfError in Stop() would also be an
effective alternative solution, but resetting on StateCallback() happens
earlier, which would be an advantage if any additional errors could possibly
be reported to StateCallback().
MozReview-Commit-ID: E9j7PQmS3O4
Because we hardcode time clamping in ESR (as opposed to having a pref) I
don't see a way to guarentee that this test won't fail when we lose the
race and clamp downwards.
MozReview-Commit-ID: IMwejbOBmDu
Because we added a new file, we rearranged the Unified Build order and now
need to fully qualify BorrowedAttrInfo which previously inherited a using statement.
MozReview-Commit-ID: BD45k5t9dQU
--HG--
extra : transplant_source : o%E5%3B%E2dr%DF%A1cP%5E%17%19%19%FF%E1%27%A3%9F%99
Backport to ESR where we don't have the ResistFingerprinting component.
MozReview-Commit-ID: 9bjycHjR3SF
--HG--
extra : transplant_source : %EA%03%21%0A%E9%3F%8E%CD%7C%D79f%96%85%96%00%5D%7F%95X
In the previous code, a race condition could cause us to call SendSetPriority() after calling SendDeleteSelf.
For example:
T1: SendDeleteSelf()
T2: if (!mIPCClosed) SendSetPriority()
T1: mIPCClosed = true
MozReview-Commit-ID: 3XOwCaphb2o
--HG--
extra : rebase_source : d6e6886402d1e0b0afed23c25a9fb18d8ca29ad6
extra : intermediate-source : cfc9afe916091e6449f7d748991e2a19187dc817
extra : source : 4ebdab0e332892378558817e30d0138c95199ce5
We're not actually using it, and it messes up with the zone allocator in
mozjemalloc after fork(). See the lengthy analysis in
https://bugzilla.mozilla.org/show_bug.cgi?id=1424709#c34 and following.
--HG--
extra : rebase_source : b191048290a907cc7668ad7ab6369ef8661f31dc
extra : intermediate-source : 45c5d467a46077dcc3ccd59feafd0c2784432fef
extra : source : bf1efa161edb20a83fe8db2f96c51f4e66880153
