This should avoid destruction messages from deleting the actor while the intr message is awaiting a response.
--HG--
extra : rebase_source : b45e8ffcfe6f63213a289aac874fd43cb71a54ec
The old code would do the content process portion of the open by
immediately sending a message back to the content process, but this
has some weird issues with nesting and priorities. Instead of doing
that, I return the endpoint for the content process back to the
original sync call. This requires more code changes, to thread the
endpoint along, but it is conceptually simpler.
Once I removed the bridges and got it working, I was just able to
remove the spawns from the IPDL file and it worked.
MozReview-Commit-ID: 1tfiJrV4jbV
--HG--
extra : rebase_source : 1ce0012d3f51b0cdebb1954cf473811a9d6c47a7
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
The last useful references to this were removed in bug 1250046, when we
deleted Shumway-specific IPC support. All this code is doing now is
taking up space.
Adds plugin variables NPPVpluginRequiresAudioDeviceChanges and NPNVaudioDeviceChangeDetails on Windows.
--HG--
extra : rebase_source : ff18bbca9772352b18be1dfcde90570775e8d5cc
The class name clashes with mozilla::net::OfflineObserver and ends up crashing in nsTraceRefcnt::GetBloatEntry because the two classes have a different size.
When PluginInstanceChild receives native key events, it should post the events to the chrome process first for checking if the key combination is reserved. However, posting all key events to the chrome process may make damage to the performance of text input. Therefore, this patch starts to post a key event whose key combination may be a shortcut key. However, for avoiding to shuffle the event order, it posts following key events until all posted key events are handled by the chrome process.
For receiving response from widget, this patch defines nsIKeyEventInPluginCallback. It's specified by nsIWidget::OnWindowedPluginKeyEvent() for ensuring the caller will receive the reply. Basically, the caller of nsIWidget::OnWindowedPluginKeyEvent() should reply to the child process. However, if the widget is a PuppetWidget, it cannot return the result synchronously. Therefore, PuppetWidget::OnWindowedPluginKeyEvent() returns NS_SUCCESS_EVENT_HANDLED_ASYNCHRONOUSLY and stores the callback to mKeyEventInPluginCallbacks. Then, TabParent::HandledWindowedPluginKeyEvent() will call PuppetWidget::HandledWindowedPluginKeyEvent().
MozReview-Commit-ID: G6brOU26NwQ
--HG--
extra : rebase_source : 8140456de278956d2d594e85c7b397ae366b4962
I also add some missing data to the content version, namely the duration of time that ContentParent::SendLoadPlugin takes.
MozReview-Commit-ID: 8qSZopvY1D7
--HG--
extra : rebase_source : ca717c149a52ed1ece9ac0678dca0c284ab26c5d
mContentParent is really just to be used while handling a synchronous
ContentParent::RecvLoadPlugin call when async plugin init turned on.
In any other context, using it will be unsafe.
This patch adds comments and assertions to ensure that this value isn't set
otherwise, and converts the one use of mContentParent outside of async plugin
init to use an alternative mechanism for identifying the content process.
MozReview-Commit-ID: Esgt1kj0MCt
--HG--
extra : rebase_source : 166b913b401582c6948e4b61efc102dc1b9c8d2f
We need to let ContentParent and PluginModuleParent get a reference to the ProfileGatherer
during the window of time that we're profiling so that if they start to die (the actor is
starting to go away), they have a gatherer they can send their last profile data to.
--HG--
extra : commitid : LkcpDsiXmp0
extra : rebase_source : d1c9e6e7640ff759cef25920e2bc17c0484544bd
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
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
The run ID for a plugin is retrieved and cached in the nsObjectLoadingContent
on plugin instantiation.
--HG--
extra : rebase_source : d1e87b7751e6367c482b2420aa43bfadbce5e3e8
Normally, this could be served by the process ID of a plugin, however, run ID is meant
to be consumed by multi-process browser chrome code for telling different runs of a
plugin apart (for example, for searching the DOM for a crashed instance of a plugin,
while ensuring that we don't accidentally find newly spawned instances that have not
crashed). Exposing something as low-level as the process ID to browser chrome code
seemed like Too Much Information. Also, there is the extremely unlikely chance that
a process ID might be re-used immediately after the original process shuts down. This
run ID avoids that case, regardless of how unlikely.
--HG--
extra : rebase_source : 4f0072ef660645efdb26d8fa7c9f03dfc60a4f4a
