For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Recv/Answer methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18132
--HG--
extra : moz-landing-system : lando
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Alloc/Dealloc methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18131
--HG--
extra : moz-landing-system : lando
When calling a Recv/Alloc/Dealloc method on most types, cast `this` to the
derived class.
There is a heuristic to figure out what the correct derived type is. There is a
blacklist of types which we can't do direct calls on for the moment, as well as
an override for types that do work with direct calls but which don't match the
heuristic.
Differential Revision: https://phabricator.services.mozilla.com/D16492
--HG--
extra : moz-landing-system : lando
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
When we shutdown the browser while the GMPService is active we can end up
leaking a GMPParent, GeckoMediaPluginServiceParent, and a Runnable. I tracked
this down to the runnable dispatched to the GMP thread in
GMPParent::ChildTerminated(). The dispatch of this runnable is failing as we
are dispatching the runnable to a reference of the GMP thread which we have
previously acquired, but that thread is now shutdown. So the dispatch fails,
and if you look in nsThread::DispatchInternal() you'll see that we deliberately
leak the runnable if dispatch fails! The runnable leaking means that the
references it holds to the GMPParent and the GMP service parent leak.
The solution in this patch is to not cache a reference to the GMP thread on the
GMPParent; instead we re-request the GMP thread from the GMPService when we
want it. This means that in the case where the browser is shutting down,
GMPParent::GMPThread() will return null, and we'll not leak the runnable. We'll
then follow the (hacky) shutdown path added in bug 1163239.
We also need to change GMPParent::GMPThread() and GMPContentParent::GMPThread()
to return a reference to the GMP thread with a refcount held on it, in order
to ensure we don't race with the GMP service shutting down the GMP thread
while we're trying to dispatch to in on shutdown.
MozReview-Commit-ID: CXv9VZqTRzY
--HG--
extra : rebase_source : e507e48ee633cad8911287fb7296bbb1679a7bcb
This removes the open of PGMPContent from PGMP, the bridge of
PGMPService and PGMP from PGMPContent, and the spawn of PGMP from
PGMPService. I did these changes all at once because the way the
bridges works it was hard to split it up.
--HG--
extra : rebase_source : d9311e3047b9855ad422838f5a8b6bfdc382d225
Now that we're not supporting Adobe EME anymore, we don't need to
provide a mechanism for GMPs to block browser shutdown.
MozReview-Commit-ID: KUC94IBQiod
--HG--
extra : rebase_source : ed521f28e272de11b2d0c4546b98baf6bd7c6e72
In a similar vein to the previous patch, while we're waiting on a
GetContentParent promise to resolve, we don't want the GMPParent
to shutdown. So make IsUsed() check whether we're waiting on a
GetContentParent promise to resolve, so we don't pull the rug out
from under any code waiting to get a content parent to bridge a
GMP.
MozReview-Commit-ID: 8cTCuXLXMsK
--HG--
extra : rebase_source : 8cc04d57ea1ef4e48c7ff088dbb12eabe4b3b223
extra : source : f79a51d9bd193024f7359ba6ff75076b15d15faf
We will use the new type for the generated IPDL message handler
prototype to make sure correct error handling method is called.
MozReview-Commit-ID: AzVbApxFGZ0
In order to avoid doing a synchronous call from content process to chrome
process in order to determine what GMPs are usable, maintain a cache of GMP
capabilities in the content processes.
We must seed the cache when content processes are created, as the GMP service
is started up and GMPs are added to it before the first (or any subsequent)
content process is created.
MozReview-Commit-ID: Eb4Pu81XHmn
--HG--
extra : rebase_source : ef5de4dd17ee337ca378569691e55d4cfb7939ef
Instead of controlling visibility of EME keysystems by build config, do it by
preference. This means keysystems can be turned on easier.
MozReview-Commit-ID: Ky1zrHPubOJ
--HG--
extra : rebase_source : 35d9c26436a86683b902225e7b0d6645b02d8ff9
Instead of controlling visibility of EME keysystems by build config, do it by
preference. This means keysystems can be turned on easier.
MozReview-Commit-ID: Ky1zrHPubOJ
--HG--
extra : rebase_source : 7d68ad8389afdac8fcfffd2c505f8467107c05a5
This makes it easier to chain promises returned by GMPParent::Init() with calls
to GMPServiceParent::LoadFromEnvironment() in the next patch.
MozReview-Commit-ID: KdGVvzAedJW
This means we won't try to build it when ac_add_options --enable-eme=widevine is
not present, and critically, we won't try to build it on Android, since the Chromium
Widevine plugin isn't available there.
MozReview-Commit-ID: 1jQvAbJP8HG
This means that when initializing the Widevine CDM, we will be able to asynchronously
parse its manifest.json on the main thread, as the WebIDL JSON parser only runs there.
MozReview-Commit-ID: GI1sc4x4m16
The only reason we need to parse the info file in the GMP child process
is because we need to read the "Libs:" line so that the child process
can preload DLLs on Windows. We already parse the GMP info file in the
parent process, so we can remove the need to parse it again if we parse
the "Libs" field in the parent, and pass that through to the child.
Thanks to bug 1121676, GMPParent does not need to be created and destroyed
on the main thread. Main-thread constraints have been removed.
Also, this means that GeckoMediaPluginServiceParent::ClonePlugin() and
AddOnGMPThread (running on the GMP thread) do not need to sync-dispatch the
creation on the main thread.
This should remove the deadlock that prevents
GeckoMediaPluginServiceParent::UnloadPlugins() from running on the GMP thread.
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
