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
The goal here is to assign a DocGroup to every runnable. This patch labels all
IPC message handlers for PPluginInstance with the DocGroup of the plugin
instance's document.
MozReview-Commit-ID: 6OIard9n2GB
The goal here is to assign a DocGroup to every runnable. This patch labels all
IPC message handlers for PPluginInstance with the DocGroup of the plugin
instance's document.
MozReview-Commit-ID: 6OIard9n2GB
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
With this change, MessageChannel stores mListener as an IToplevelProtocol
rather than a MessageListener (which isn't really a useful concept on
its own). The MessageListener methods are split out to IProtocol and
IToplevelProtocol. MessageListener gets deleted. Some of the inline
functions in MessageChannel had to be moved to MessageChannel.cpp since
IToplevelProtocol isn't defined in MessageChannel.h.
With this change, MessageChannel stores mListener as an IToplevelProtocol
rather than a MessageListener (which isn't really a useful concept on
its own). The MessageListener methods are split out to IProtocol and
IToplevelProtocol. MessageListener gets deleted. Some of the inline
functions in MessageChannel had to be moved to MessageChannel.cpp since
IToplevelProtocol isn't defined in MessageChannel.h.
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 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
Callers should use a UniquePtr to hold the platform handle.
MozReview-Commit-ID: 6BWnyAf4b3a
--HG--
extra : transplant_source : %26%CA%0D%28%08%9BT%97Z%A1%3Dq%CD%21%A1_%EFE%83%0E
extra : histedit_source : 77f8ed3d0fdec6cce0c95469130ade0fb547bb91
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
