corysanin/tubestation
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Bug 1257759 part.5 PluginInstanceChild should post received native key event to chrome process if the key combination may be a shortcut key r=jimm

Browse Source 
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
This commit is contained in:
Masayuki Nakano
2016-04-19 20:09:37 +09:00
parent a42732a6b2
commit bbce223b06
31 changed files with 674 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

51
dom/plugins/base/nsPluginInstanceOwner.cpp
View File

@@ -418,6 +418,7 @@ NS_IMPL_ISUPPORTS(nsPluginInstanceOwner,
nsIPluginInstanceOwner,
nsIDOMEventListener,
nsIPrivacyTransitionObserver,
nsIKeyEventInPluginCallback,
nsISupportsWeakReference)
nsresult
@@ -993,8 +994,58 @@ nsPluginInstanceOwner::RequestCommitOrCancel(bool aCommitted)
}
return true;
}
#endif // #ifdef XP_WIN
void
nsPluginInstanceOwner::HandledWindowedPluginKeyEvent(
const NativeEventData& aKeyEventData,
bool aIsConsumed)
{
if (NS_WARN_IF(!mInstance)) {
return;
}
nsresult rv =
mInstance->HandledWindowedPluginKeyEvent(aKeyEventData, aIsConsumed);
NS_WARN_IF(NS_FAILED(rv));
}
void
nsPluginInstanceOwner::OnWindowedPluginKeyEvent(
const NativeEventData& aKeyEventData)
{
if (NS_WARN_IF(!mPluginFrame)) {
// Notifies the plugin process of the key event being not consumed by us.
HandledWindowedPluginKeyEvent(aKeyEventData, false);
return;
}
nsCOMPtr<nsIWidget> widget = mPluginFrame->PresContext()->GetRootWidget();
if (NS_WARN_IF(!widget)) {
// Notifies the plugin process of the key event being not consumed by us.
HandledWindowedPluginKeyEvent(aKeyEventData, false);
return;
}
nsresult rv = widget->OnWindowedPluginKeyEvent(aKeyEventData, this);
if (NS_WARN_IF(NS_FAILED(rv))) {
// Notifies the plugin process of the key event being not consumed by us.
HandledWindowedPluginKeyEvent(aKeyEventData, false);
return;
}
// If the key event is posted to another process, we need to wait a call
// of HandledWindowedPluginKeyEvent(). So, nothing to do here in this case.
if (rv == NS_SUCCESS_EVENT_HANDLED_ASYNCHRONOUSLY) {
return;
}
// Otherwise, the key event is handled synchronously. Let's notify the
// plugin process of the key event's result.
bool consumed = (rv == NS_SUCCESS_EVENT_CONSUMED);
HandledWindowedPluginKeyEvent(aKeyEventData, consumed);
}
NS_IMETHODIMP nsPluginInstanceOwner::SetEventModel(int32_t eventModel)
{
#ifdef XP_MACOSX