This means if WebAudio is using the Adobe GMP for decoding and it crashes,
we'll get a crash report for the GMP.
MozReview-Commit-ID: FOZoPxvUwq5
--HG--
extra : rebase_source : 0641e4c46619693b2983a7d7297af525f1ac5bea
So if a GMP crashes while doing EME, we'll get a crash report using the new
mechanism.
MozReview-Commit-ID: G8BlFI9jmiF
--HG--
extra : rebase_source : 1cda5c93ea9e547636b34ec2149ef9cd2506ca73
Disconnecting the GMPCrashHelpers at the right time is hard, because in the
crashing case we're all shutdown before the GMPCrashHelpers can be invoked to
help handle the crash report. So add a class to help the helpers;
GMPCrashHelperHolder. This composes into the GMP content protocol actors, to
help them disconnect the crash helpers at the right time. See the comment in
GMPCrashHelperHolder for the details.
MozReview-Commit-ID: E5rE6e5Jues
--HG--
extra : rebase_source : f688bf727f23f773eb995611cec6412ebf021029
This enables callers to specify a way to determine the correct window to
dispatch the PluginCrashed event to should the GMP actor crash.
We need a way to determine the correct window at crash time, as the GMP's
window can change at runtime. For example, if the GMP is being used for
unencrypted decoding, the <video> element can be moved to a new browser window
at runtime.
Note: I don't handle disconnecting the GMPCrashHandlers in this patch; we do
delete the GMPCrashHandlers in this patch when their associated GMP crashes, and
in the next patch we handle disconnecting GMPCrashHandlers in the case where
we don't crash.
MozReview-Commit-ID: DrwcZAB6Ys0
--HG--
extra : rebase_source : 8da188b68456914773e6adae8cbccd6bf6a6e7a7
This will allow us to attach a crash handler to a GMP process after deciding
which GMP to load but before actually loading it.
MozReview-Commit-ID: HwBZU2Q4TX6
--HG--
extra : rebase_source : a68b9cbc31c0b886ba491f8f15f02e4d0e32cae7
This means we can return already_AddRefed<T> for any RefPtr<T>s
being held as instance variables easier.
MozReview-Commit-ID: HFHdkF8EUsK
--HG--
extra : rebase_source : df650d39c010386afcb8cb2dd48292c26fbc6501
They're no longer in the spec, and we and Chrome have supported the up to date
versions for a while.
MozReview-Commit-ID: 3OBpPuua7GW
--HG--
extra : source : d9122e818c36fc0e2381ae469988a96324e5557d
I had meant to remove all of these in bug 1276132, but I missed a couple. We
should now check whether Widevine is enabled before hitting these code paths
by checking the preference.
MozReview-Commit-ID: FmAdlgbF0Py
--HG--
extra : source : 586eff45c5479c7efc86435add5f6e9edd5e43b0
extra : amend_source : 65a9902374155d9e3180f0510b1d1434b986dc83
(In some cases, I've left "ImageLogging.h" being included before the corresponding .h file, because I ran across a warning comment saying that it needs to be included before any IPDL-generated files & anything that includes prlog.h; and it seems possible that Foo.cpp's corresponding Foo.h file could include such headers now or in the future.)
MozReview-Commit-ID: HPvUVj8YuKc
I found these issues locally by moving all of imagelib's .cpp files to SOURCES instead of UNIFIED_SOURCES. (That change isn't part of this patch, though.)
MozReview-Commit-ID: 97Xpfu8eFE6