Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
This patch converts all the prefs in MediaPrefs to the new StaticPrefs system.
Note that the "media.wmf.skip-blacklist" pref was present in both MediaPrefs
and gfxPrefs. The copy in MediaPrefs was never used; this explains why this
patch does not add an entry for it to StaticPrefList.h.
Note also that the patch removes themedia.rust.mp4parser pref, because it's
unused.
MozReview-Commit-ID: IfHP37NbIjY
--HG--
extra : rebase_source : df84ea813b7c366d7be663c696891325610149c8
We should not use LoadLibraryA (or more generally "A" functions) on Windows
because it is lossy. Bug 1440886 will introduce a static analysis to prevent
potential misuse of LoadLibraryA, so we need to replace existing usages first.
MozReview-Commit-ID: 6krgrVcSHNW
--HG--
extra : rebase_source : 0e93acecfe0c9ccd2e4ba9ad3126b6ae16433387
Around every Firefox update, Netflix see a spike in
MediaKeySystemAccess.createMediaKeys() promise rejects. I am wondering whether
this is caused by the browser restarting to apply a Firefox update while
Netflix's player is loading. So add more detail to the promise reject as to
the state of the system, to try to validate that theory.
MozReview-Commit-ID: 4IDPsFwKCtq
--HG--
extra : rebase_source : 0a53acb623f895e598845c281edc73b926c74c28
Respect MOZ_DISABLE_GMP_SANDBOX so that the GMP sandbox
can be disabled from the command line.
MozReview-Commit-ID: HLHQ6ImrzGe
--HG--
extra : rebase_source : 54335b6f612f5b09e2680ec6e6dee70f37a99e2b
The CDM on Mac and Windows will ask the host for storage id.
We compute the storage id by hashing machine id, origin salt and browser id.
MozReview-Commit-ID: 4fTCaOKgSIe
--HG--
extra : rebase_source : 20fe8ab93966bb74b46eebbfbddc8486ceea4705
The reason explained in patch Part1 of Bug 1214018 and I just copy the reason below.
GetRawMachineId was returning its generated data through a 'string16', which on
Windows was conveniently equivalent to a std::wstring.
However on Mac, wstring uses 32-bit characters, so in order to comply with the
string16 interface, a lot of non-trivial code would have to be imported and
vetted.
Also, in the end GMPLoader::Load passes this string16 to SHA256_Update() as a
sequence of bytes, the actual type of the data is lost!
So to simplify this work, GetRawMachineId will now return its data through a
vector of bytes, and the platform-dependent implementations may use whatever
data type they want internally.
The Windows GetRawMachineId actually returns the same data in this vector, so
it stays compatible with the previous code.
MozReview-Commit-ID: 7xYgjndXWDX
--HG--
extra : rebase_source : 6a46bd7f06d6e4bc10bb98b600e7e5bc14c136ce
Chromium uses rlz_lib::GetMachineId as a factor when calculating storage id.
MozReview-Commit-ID: AJbcnRXzi3m
--HG--
extra : rebase_source : 4e6a0eebaeec01fc7a78caeb8406d1e2ed09f1d4
Sync with the upstream(Chromium src/rlz/) and try to revert the functionality of Bug 1332530.
rlz is linked into xul.
MozReview-Commit-ID: HsjnBRPnifh
--HG--
extra : rebase_source : 2867fe353d0c8c67535d29943f3536ef59d1d75e
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.
--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
Using a single-function MozPromise::Then, and capturing a UniquePtr (using
C++14 initialized lambda captures), the PromiseHolder cannot leak anymore.
Also using C++ initialized lambda captures for other variables, to avoid
unnecessary constructions and copies.
MozReview-Commit-ID: DVxyuJNa8YX
--HG--
extra : rebase_source : a7169d616da36597854bf37616228eb72636f2b7
Originally, we use IPC_FAIL_NO_REASON to make IPC call return error and then it invokes MOZ_CRASH to kill the process itself.
By using IPC_FAIL, we can pass a descriptive reason to GMPChild::ProcessingError and Bug 1416667 will use MOZ_CRASH_UNSAFE_PRINTF
to print the reason to the crash report. In addition, we use CrashReporter::AnnotateCrashReport to record the lib path without exposing the data publicly.
MozReview-Commit-ID: 15n1PItLgAp
--HG--
extra : rebase_source : 011f02155b290f95fcde807264f3e1ffb9a09e80
We passed the crash reason to GMPChild::ProcessingError but we didn't use it anymore.
We can simply use MOZ_CRASH_UNSAFE_PRINTF instead of MOZ_CRASH to make the crash more descriptive.
MozReview-Commit-ID: D7mU3Dsg9V9
--HG--
extra : rebase_source : 467974fbcc81792850b6c4b1a6faa3e90cfabb41
This was used to support cross-architecture NPAPI plugins on OS X, but
we stopped supporting that in 54 (bug 1339182).
MozReview-Commit-ID: 2BcWYD6mguY
--HG--
extra : rebase_source : 6e509a3cc1f356ccd24f1459c43bc8fb66d7b0f4
