Bug 1187724 - Don't dispatch KeyboardEvents when the target of WM_APPCOMMAND is a windowed plug-in for preventing deadlock. r=jimm, a=ritu
authorMasayuki Nakano <masayuki@d-toybox.com>
Mon, 10 Aug 2015 23:54:18 +0900
changeset 288906 f6ed87e5d6419912ef4f21b63905529f66112bb7
parent 288905 5b295583cfc163188107da3a7d40600e521705d7
child 288907 5573079c91183242fd106079ea99191aa8d7f4bd
push id5067
push userraliiev@mozilla.com
push dateMon, 21 Sep 2015 14:04:52 +0000
treeherdermozilla-beta@14221ffe5b2f [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersjimm, ritu
bugs1187724
milestone42.0a2
Bug 1187724 - Don't dispatch KeyboardEvents when the target of WM_APPCOMMAND is a windowed plug-in for preventing deadlock. r=jimm, a=ritu
widget/windows/KeyboardLayout.cpp
--- a/widget/windows/KeyboardLayout.cpp
+++ b/widget/windows/KeyboardLayout.cpp
@@ -1291,16 +1291,24 @@ NativeKey::HandleAppCommandMessage() con
 
   // Let's dispatch keydown message before our chrome handles the command
   // when the message is caused by a keypress.  This behavior makes handling
   // WM_APPCOMMAND be a default action of the keydown event.  This means that
   // web applications can handle multimedia keys and prevent our default action.
   // This allow web applications to provide better UX for multimedia keyboard
   // users.
   bool dispatchKeyEvent = (GET_DEVICE_LPARAM(mMsg.lParam) == FAPPCOMMAND_KEY);
+  if (dispatchKeyEvent) {
+    // If a plug-in window has focus but it didn't consume the message, our
+    // window receive WM_APPCOMMAND message.  In this case, we shouldn't
+    // dispatch KeyboardEvents because an event handler may access the
+    // plug-in process synchronously.
+    dispatchKeyEvent =
+      WinUtils::IsOurProcessWindow(reinterpret_cast<HWND>(mMsg.wParam));
+  }
 
   bool consumed = false;
 
   if (dispatchKeyEvent) {
     WidgetKeyboardEvent keydownEvent(true, NS_KEY_DOWN, mWidget);
     InitKeyEvent(keydownEvent, mModKeyState);
     // NOTE: If the keydown event is consumed by web contents, we shouldn't
     //       continue to handle the command.