TextEventDispatcher initializes charCode value with mKeyValue (and mKeyNameIndex) of WidgetKeyboardEvent. Therefore, NativeKey needs to initialize mKeyValue properly at handling WM_KEYDOWN message of VK_PACKET. However, nobody initializes mCommittedCharsAndModifiers value of VK_PACKET. Additionally, KeyboardLayout::ConvertNativeKeyCodeToKeyNameIndex() returns KEY_NAME_INDEX_Unidentified for it too.
Therefore, this patch creates a path for handling VK_PACKET. First, makes KeyboardLayout::ConvertNativeKeyCodeToKeyNameIndex() returns KEY_NAME_INDEX_USE_STRING. Next, the constructor of NativeKey initializes mCommittedCharsAndModifiers with following char message. Additionally, makes sure that VK_PACKET is always handled with following char message even if there is no char message.
nsWindow for Windows cannot decide if a preceding WM_*KEYDOWN or WM_*KEYUP which is a preceding message of WM_*CHAR is consumed because nsWindow cannot know if WM_*CHAR message came from same window which received the preceding WM_*KEYDOWN or WM_*KEYUP. Therefore, PluginInstanceChild should do that.
MozReview-Commit-ID: 1uuZ0nTJ5Xb
--HG--
extra : rebase_source : b99f8057d5e93035a769af2506292ff7d2cb8f4a
Implementing nsWindow::OnWindowedPluginKeyEvent() on Windows. This patch makes NativeKey class dispatches eKeyDownOnPlugin and eKeyUpOnPlugin when the method is called.
MozReview-Commit-ID: L8yRZvDaQKR
--HG--
extra : rebase_source : 387ce72dcea23a92bd8c774fc54a8bff8da6c844
If a plugin process posts native key events to the widget, it needs to check if the key combination is reserved by chrome because if it's reserved by chrome, the reserved shortcut key handler should be executed and the event shouldn't be handled by the focused plugin.
This patches add eKeyDownOnPlugin and eKeyUpOnPlugin. nsXBLWindowKeyHandler will listen to them and handle them as normal keydown and keypress or keyup event. Note that these events won't be fired on content in the default event group and won't be sent to the remote process.
MozReview-Commit-ID: H5OKPLtVdr6
--HG--
extra : rebase_source : c6852423e47c40e9953b72061262730f7cce35d7
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
PluginInstanceChild needs to send native key event to the chrome process via a content process. So, IPC needs a platform independent class/struct which can store native event. This purpose is exactly same as the purpose of WidgetGUIEvent::PluginEvent. Therefore, we can use it for this case too.
This patch renames WidgetGUIEvent::PluginEvent to NativeEventData but this patch does NOT remove WidgetGUIEvent::PluginEvent. Instead of that, it's defined as an alias of NativeEventData since PluginEvent is clearer name for the original purpose and it's used by plugin module.
MozReview-Commit-ID: 3nrHfb8gk8m
--HG--
extra : rebase_source : b0b5a863360bf0893b161d70124d3a83aa2c3386
Before posting native key message from PluginInstanceChild, we need to check if the key combination could be a shortcut key, i.e., we need to check if Ctrl or Alt key is pressed. ModifierKeyState is a good class for checking it but it should be defined in an independent header file.
This patch separates the definition of ModifierKeyState to mozilla/widget/WinModifierKeyState.h and implement MaybeMatchShortcutKey() for PluginInstanceChild.
MozReview-Commit-ID: ZjLnJx02Ou
--HG--
rename : widget/windows/KeyboardLayout.h => widget/windows/WinModifierKeyState.h
extra : rebase_source : 66e9351a36dfa88f080ea78972ac0cb347bb174d
This patch separates Windows' message definition and related definitions from nsWindowDefs.h to mozilla/widget/WinMessages.h because the definitions are useful in plugin module but nsWindowDefs.h cannot be included from plugin module since it depends on some headers in under widget.
MozReview-Commit-ID: KNUAffLMKT1
--HG--
rename : widget/windows/nsWindowDefs.h => widget/windows/WinMessages.h
extra : rebase_source : ae9390e700ca97a0a4eea3b2977d4d5568ce9408
nsContenUtils::GetSurfaceData() returns an allocated buffer; the uses of
it in PuppetWidget and nsContentUtils::TransferableToIPCTransferable
copy the allocated buffer again. We can do better than this. In the
PuppetWidgetCase, we can simply construct an nsDependentCString for
sending the IPC message. In the TransferableToIPCTransferable case, we
can transfer ownership of the buffer into the IPCDataTransferItem we are
creating.
