When GMPService::GetContentParent returns a MozPromise, we end up failing in
test_peerConnection_scaleResolution.html with e10s enabled because we Close()
the GMPContentParent twice. The test causes two GMPVideoEncoderParents to
be created. When the number of IPDL actors on the GMPContentParent reach 0,
we close the IPC connection. With GetContentParent() returning a MozPromise,
it's more async, and so we can end up requesting the content parent in order
to create the second GMPVideoEncoderParent, but while we're waiting for
the promise to resolve the previous GMPVideoEncoderParent is destroyed and
the GMPContentParent closes its IPC connection. Then the GetContentParent
promise resolves, and that fails to operate correctly since it's closed its
IPC connection.
My solution here is to add a "blocker" that prevents the GMPContentParent from
being shutdown while we're waiting for the GetContentParent promise to resolve.
MozReview-Commit-ID: HxBkFkmv0tV
--HG--
extra : rebase_source : 59aa7bcfe8b8f44274d136d6147a946542a64fff
extra : source : 59ab10349b58b0fbe13dca9312ec82332f7c3dbe
Retrieve the ID of the GMPDecryptor from the GMPCDMProxy, and pass that
through to the GMPVideoDecoder's constructor.
MozReview-Commit-ID: IuNsSroZ9Zu
--HG--
extra : rebase_source : d678628dec67a059aec06918f07ea93ecc54a5f9
Retrieve the ID of the GMPDecryptor from the GMPCDMProxy, and pass that
through to the GMPVideoDecoder's constructor.
MozReview-Commit-ID: IuNsSroZ9Zu
--HG--
extra : rebase_source : 6f1db4a019deaedac07fa15c1958270268dcb941
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
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
GeckoMediaPluginService::mAbstractThread was not reset as expected from
ShutdownGMPThread, meaning it would retain a reference to the GMP thread, and
it would allow dispatch attempts to the GMP thread after shutdown.
Also mAbstractThread was not protected by a mutex (as mGMPThread was), which is
definitely needed now that it can be reset at shutdown time.
As its prefix implies, GetAbstractThread could return a nullptr, so it should
be checked before every use.
Note that this GetAbstractThread call (and its check) has been moved closer to
the start of functions using it, to avoid unnecessary and potentially invariant-
breaking partial work to take place when we can know in advance that it won't
fully succeed because the GMP thread is not available.
MozReview-Commit-ID: B1drOeM65hr
--HG--
extra : rebase_source : 1d389c663e26a25035bf2aa22b2cca478ef954fe
Crash reporting for GMPs being used from the EME call site are not generating
crash reports because they depend on the MediaKeys object calling
GMPService::AddPluginCrashHandler() to associate a window to which the
PluginCrashedEvent is fired. This doesn't work with e10s enabled because the
GMPParent which causes the plugin crash handlers to run is in the chrome
process, but the MediaKeys which adds the handler is in the child process. So
the crash handler is on the GMPServiceChild, but we only run the crash handlers
that were added to the GMPServiceParent in the chrome/parent process.
The solution is to broadcast a message from the chrome process to all the
content processes when a GMP has crashed that causes the GMPServiceChild to
also run its crash handlers.
MozReview-Commit-ID: 8Lek16G9ZGb
--HG--
extra : rebase_source : 180691046812df474ea33324d2b98ac71d11c9cd
XPCOMThreadWrapper::GetCurrent() is failing because it's not keeping
AbstractThread::sCurrentThreadTLS up to date. This causes assertion failures
during startup of the GMP stack when dispatching via InvokeAsync to the GMP
thread, which is an XPCOM thread wrapped by the XPCOMThreadWrapper.
We can trivially initialize AbstractThread::sCurrentThreadTLS to be the
XPCOMThreadWrapper on the target thread, since it's thread-local-storage, and
the target thread won't change.
MozReview-Commit-ID: EIEFZppR2PS
I need to make GMPParent::Init() async, because the WebIDL JSON parsing
must happen on the main thread, and GMPParent::Init() is called on the
GMP thread, so I need GMPParent::Init() to be async so that in the
Chrome manifest case it can dispatch a task to the main thread to parse
the Chrome manifest before completing. So I'll make GMPParent::Init()
return a promise, and to do that, I need the GMP thread to have an
AbstractThread wrapper.
MozReview-Commit-ID: 44b4Z4jpar8
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
This is straightforward mapping of PR_LOG levels to their LogLevel
counterparts:
PR_LOG_ERROR -> LogLevel::Error
PR_LOG_WARNING -> LogLevel::Warning
PR_LOG_WARN -> LogLevel::Warning
PR_LOG_INFO -> LogLevel::Info
PR_LOG_DEBUG -> LogLevel::Debug
PR_LOG_NOTICE -> LogLevel::Debug
PR_LOG_VERBOSE -> LogLevel::Verbose
Instances of PRLogModuleLevel were mapped to a fully qualified
mozilla::LogLevel, instances of PR_LOG levels in #defines were mapped to a
fully qualified mozilla::LogLevel::* level, and all other instances were
mapped to us a shorter format of LogLevel::*.
Bustage for usage of the non-fully qualified LogLevel were fixed by adding
|using mozilla::LogLevel;| where appropriate.
This is straightforward mapping of PR_LOG levels to their LogLevel
counterparts:
PR_LOG_ERROR -> LogLevel::Error
PR_LOG_WARNING -> LogLevel::Warning
PR_LOG_WARN -> LogLevel::Warning
PR_LOG_INFO -> LogLevel::Info
PR_LOG_DEBUG -> LogLevel::Debug
PR_LOG_NOTICE -> LogLevel::Debug
PR_LOG_VERBOSE -> LogLevel::Verbose
Instances of PRLogModuleLevel were mapped to a fully qualified
mozilla::LogLevel, instances of PR_LOG levels in #defines were mapped to a
fully qualified mozilla::LogLevel::* level, and all other instances were
mapped to us a shorter format of LogLevel::*.
Bustage for usage of the non-fully qualified LogLevel were fixed by adding
|using mozilla::LogLevel;| where appropriate.
This is straightforward mapping of PR_LOG levels to their LogLevel
counterparts:
PR_LOG_ERROR -> LogLevel::Error
PR_LOG_WARNING -> LogLevel::Warning
PR_LOG_WARN -> LogLevel::Warning
PR_LOG_INFO -> LogLevel::Info
PR_LOG_DEBUG -> LogLevel::Debug
PR_LOG_NOTICE -> LogLevel::Debug
PR_LOG_VERBOSE -> LogLevel::Verbose
Instances of PRLogModuleLevel were mapped to a fully qualified
mozilla::LogLevel, instances of PR_LOG levels in #defines were mapped to a
fully qualified mozilla::LogLevel::* level, and all other instances were
mapped to us a shorter format of LogLevel::*.
Bustage for usage of the non-fully qualified LogLevel were fixed by adding
|using mozilla::LogLevel;| where appropriate.
When a method returns type D derived from RefCounted type B, there is an
ImplicitCastExpr (or an ExplicitCastExpr, if there is an explicit cast
to the base type in the code) in the AST between the CallExpr and
MemberExpr, which we didn't take into account before. This caused the
analysis to not work on common patterns such as
nsCOMPtr<nsIXPCOMInterface>.