TSFTextStore shouldn't append any ranges to dispatch empty composition event since empty clause information may make TextComposition confused. Additionally, it doesn't need to append caret range because CompositionTransaction always sets caret at start of composition when the composition string is empty.
MozReview-Commit-ID: Iu8IWwEOxaf
--HG--
extra : rebase_source : 70b56c6d4caee309615170aee70f28d8c3eb7d92
When NativeKey tries to remove a char message from the queue, another NativeKey instance might be created due to odd API hook or something. In such case, the old instance should handle the received message and the new instance should do nothing for keeping the order of message handling.
This patch makes:
* NativeKey::GetFollowingCharMsg() store removing char message to mRemovingMsg before calling PeekMessage() with PM_REMOVE.
* NativeKey::InitWithChar() set the old instance's mReceivedMsg to the received char message and do nothing even if HandleCharMessage() is called later.
* NativeKey::GetFollowingCharMsg() return received char message if mReceivedMsg is set during a call of PeekMessage().
MozReview-Commit-ID: KXYW0GgC9AY
--HG--
extra : rebase_source : 08472dec28e93450cd04a367843c1511cb812a9c
For detecting nested creation of NativeKey instances, NativeKey should manage the latest instance with sLastestInstance for the other instances and previous instance with mLastInstance.
MozReview-Commit-ID: BFZ0cr1640S
--HG--
extra : rebase_source : e2439a21f5984c6246283924c2013038c734ae2a
For logging message, we should have better log text generator for MSG.
Then, we can improve the note of crash reports which is appended in NativeKey::GetFollowingCharMessage().
MozReview-Commit-ID: 4sbZJaWFH2o
--HG--
extra : rebase_source : bbc3101a78e4e2aa8b5eb0f68cd6f3605ba924f6
Currently, NativeKey::DispatchPluginEventsAndDiscardsCharMessages() calls nsWindowBase::DispatchPluginEvent() and nsWindowBase::DispatchPluginEvent() does nothing when windowless plugin doesn't have focus. However, this is unclear when other developers read the code of DispatchPluginEventsAndDiscardsCharMessages() and it causes unnecessary virtual calls. So, it should try to dispatch plugin events only when a windowless plugin has focus.
For making the check safer, nsWindowBase should expose the method to check it as ShouldDispatchPluginEvent(). Unfortunately, we cannot mark this method as const due to PluginHasFocus() needs to be not const method, though. Then, for loops in DispatchPluginEventsAndDiscardsCharMessages() should check it at each try.
This change helps to log the behavior (working on bug 1297013) without noise.
Additionally, this patch renames the method to MaybeDispatchPluginEventsForRemovedCharMessages() because it doesn't remove any char messages anymore.
MozReview-Commit-ID: F14Lcx47M6U
--HG--
extra : rebase_source : 64b6da75590c99299f75358023844762198136d6
NativeKey removes odd WM_CHAR messages which are caused by ATOK or WXG if the user tries to do "Kakutei-Undo" (meaning "undo the last commit") after dispatching eKeyDown event.
However, NativeKey should remove them from the queue first because there are some problems:
* If focus is moved during dispatching an eKeyDown event, we'll fail to remove the messages from the queue.
* If dispatching eKeyDown advance native event loop due to entering to a modal loop or dosing synchronous XHR, the message pattern is broken before removing the odd messages from the queue.
After removing the odd char messages, NativeKey should store them with mRemovedOddCharMsgs because NativeKey needs to dispatch them to focused windowless plugin.
Note that this patch also fixes a bug of the loop to remove the odd WM_CHAR messages. Old code removes only one WM_CHAR messages, but we need to remove all WM_CHAR messages before WM_KEYUP. This must be a regression.
MozReview-Commit-ID: I60bcIx2SFS
--HG--
extra : rebase_source : 19d0e70d9f39e6d0476c62def5e0a2dc1e0ab444
NativeKey is now removing and storing following char messages when it's created for a keydown message. Therefore, IsFollowedByNonControlCharMessage() just refers the stored messages and it's enough fast. So, we can get rid of mIsFollowedByNonControlCharMessage.
MozReview-Commit-ID: 542A2sHNXeC
--HG--
extra : rebase_source : e748c9855c3cf2d45609f94f9ccc8d43d29dc447
GetFollowingCharMessage() is now called only when removing following char message. Therefore, it does not need to have the optional argument indicating if removing the found message.
MozReview-Commit-ID: 7P39wyfSC1
--HG--
extra : rebase_source : a38bb961df1bc03adc21295bc39e4e9c16e864f2
While dispatching an event, focused widget may be changed. In such case, NativeKey shouldn't continue to dispatch remaining events (eKeyPress events) for preventing to dispatch to input text in unexpected website.
MozReview-Commit-ID: 7geuqks0LQK
--HG--
extra : rebase_source : 3e6c82e1eb0e27115fe93b1a3b4a155914fd06f7
In some cases, we may receive following char message of WM_*KEYDOWN *during* dispatching an eKeyDown event. In such case, NativeKey shouldn't dispatch eKeyPress event twice (one is caused by receiving WM_*CHAR message, the other is caused by post dispatching eKeyDown event code).
This patch makes NativeKey consume following WM_*CHAR messages before dispatching eKeyDown. Therefore, the former case will never occur.
For doing that, NativeKey stores following WM_*CHAR messages in mFollowingCharMsgs and uses it when it needs to dispatch eKeyPress events for each WM_*CHAR message.
MozReview-Commit-ID: 6QNvlwVVlTz
--HG--
extra : rebase_source : c33b5a1ac503326d51ef78f4f8a09c9a63df7871
For safety, NativeKey::GetScanCodeWithExtendedFlag() returns without extended flag on WinXP and WinServer2003 because ::MapVirtualKeyEx() API doesn't support extend key conversion.
However, extended scan code is available even on them when lParam has 0x1000000 especially when it computes KeyboardEvent.code value. Therefore, it should return with 0xE000 for extended keys on any versions of Windows.
Note that NativeKey::ComputeVirtualKeyCodeFromScanCodeEx() wraps ::MapVirtualKeyEx() API. It checks if the API is not available for the result of NativeKey::GetScanCodeWithExtendedFlag(). So, returning extended scan code from NativeKey::GetScanCodeWithExtendedFlag() is safe.
MozReview-Commit-ID: D2RrHxPI9ET
--HG--
extra : rebase_source : 51f277e8331eb7ad109c3227ac1fe73f6de48105
On Windows, some keys are called "extended key". Their scan code include 0xE000. For example, Enter key in standard position is 0x001C but Numpad's Enter key is 0xE01C. Unfortunately, both of them cause same virtual keycode value, VK_RETURN. Therefore, currently, nsIDOMWindowUtils.sendNativeKey() can synthesize only one native key event of them (only non-extended key's event). Additionally, MapVirtualKeyEx() API with MAPVK_VK_TO_VSC (even with MAPVK_VK_TO_VSC_EX) don't return extended scancode value as expected.
For solving these issues, we should include scan code value to the virtual keycode value at calling sendNativeKey().
Fortunately, virtual keycode value on Windows is 0 ~ 255 (0x00 ~ 0xFF) but aNativeKeyCode of sendNativeKey() is int32_t. So, we can use upper 16 bit for specifying scan code.
This patch explicitly specifies scan code value at defining WIN_VK_* in NativeKeyCodes.js. Additionally, this patch duplicates native virtual keycode definition for Home, End, Insert, Delete, PageUp, PageDown, ArrowUp, ArrowLeft, ArrowDown, ArrowRight and Enter as WIN_VK_* and WIN_VK_NUMPAD_*. This makes automated tests can specify both positions' keys explicitly.
Finally, this patch adds some tests to test_keycodes.xul for testing KeyboardEvent.code value of those keys in both positions.
MozReview-Commit-ID: 8n1rQ71dilg
--HG--
extra : rebase_source : 8215e56ba1ed9fc54c04eb7ca037b12c3ced5c1b
Ctrl+Backspace causes WM_CHAR for control character DELETE. However, NativeKey::IsControlChar() doesn't treat it as a control character. Therefore, NativeKey treats Backspace key as a printable character.
MozReview-Commit-ID: 29V45CNp8kW
--HG--
extra : rebase_source : 6656d884addf8b49dfa7c12d0b2c8d0543493c4f
On some keyboard layouts, a key sequence, a dead key -> another dead key, may produce a composite character instead of two base characters for each key. For example, with "Russian - Mnemonic" keyboard layout on Win 8 or later, both 's' and 'c' are dead keys but key sequence, 's' -> 'c', produces a Unicode character.
For solving this issue, this patch fixes 2 bugs:
First, KeyboardLayout::GetDeadKeyCombinations() doesn't add dead key entry if 2nd key is a dead key (::ToUnicodeEx() returns -1). In such case, it should add a dead key entry with the first character which is produced when only the 2nd key is pressed (the character is called as "base character" and used for index of the dead key table).
Next, KeyboardLayout::InitNativeKey() should check if 2nd dead key press produces a composite character. If it's produced, it should initialize given NativeKey with the composite character. Otherwise, it should initialize with base characters of each key. This patch does it with KeyboardLayout::MaybeInitNativeKeyWithCompositeChar().
Finally, we should add automated test for this. However, unfortunately, it's not available on Win7 and our infra is still using Win7 for running automated tests. Therefore, this patch doesn't include new automated tests.
MozReview-Commit-ID: G1DrfkHKNcK
--HG--
extra : rebase_source : 6ff4278d594a26a0908464b1e603a0a7ee2b3b38
It's difficult to understand what data is created by KeyboardLayout::LoadLayout(). So, for understanding what data is created, let's add logging code into it.
MozReview-Commit-ID: CelxyVpGn5f
--HG--
extra : rebase_source : fd8f15a42c4c2b4c1f1079184060c6e5f796ac5a
Based on crash reports, and issue was fixed in later drivers.
Also blocking 15.x up to 15.301.2301.1002.
MozReview-Commit-ID: F4kJta8JH1K
--HG--
extra : rebase_source : 5f69443b72cfefde052f70e27d8cf98128b3b913
There are 2 bugs and this patch fixes them once.
First, NativeKey::WillDispatchKeyboardEvent() is used to setting alternative charCode values for every eKeyPress event. However, for supporting "reserved" shortcut keys, now, it sets alternative charCode values to eKeyDown too. However, they are really different. eKeyPress events are fired for every character to be inputted by a key press sequence. On the other hand, eKeyDown event is fired only once for a key sequence. Therefore, now, NativeKey::WillDispatchKeyboardEvent() needs to set alternative charCode values for all characters inputted by the key sequence to eKeyDown event.
The other is not a new bug. NativeKey::WillDispatchKeyboardEvent() sets the last eKeyPress event's special alternative charCode values, such as unshifted Latin character, shifted Latin character and some character which can be computed from virtual keycode. This is performed when given index is the last index of the longest input string of the key. However, the value includes different shift key state. I.e., when different shift key causes longer text input, NativeKey::WillDispatchKeyboardEvent() won't set the special alternative charCode values to any eKeyPress events. For example, when Ctrl+T is pressed with Arabic keyboard layout, its unshifted input string length is 1 but shifted input string length is 2. Then, eKeyPress event is fired only once, but NativeKey::WillDispatchKeyboardEvent() waits second eKeyPress event.
Therefore, this patch makes the method append alternative charCodes for all remaining characters and detect the last event correctly with mCommittedCharsAndModifiers (it's used for KeyboardEvent.key value of eKeyDown event and the count of eKeyPress events is same as the value's length).
MozReview-Commit-ID: 6adUnmi5KYy
--HG--
extra : rebase_source : 8c04a3a155f2fcb9a5a8b3e9e0a176c678dc6265
When investigating bug 1075194, I found that we don't check return value of DocumentPropertiesW. So we sould use correct type and add log for this API.
MozReview-Commit-ID: Ck3VwMq9OpQ
--HG--
extra : amend_source : a0da15b578055b7612ce96b44cac2cd69607fa51
This patch prevents the Windows widget code from dispatching the contextmenu
event if APZ is handling touch input. Instead, the APZ code processes the
raw touch input, and will fire a contextmenu event when the user lifts their
finger after a long-press action, in keeping with the Windows platform
convention. Doing it this way also allows us to respect web conventions where
the web content can prevent the contextmenu event from firing by calling
preventDefault on the touchstart event; this was not possible when dispatching
the contextmenu event directly from the widget code.
This also makes long-pressing on browser chrome components work properly, as
it just shifts the point in time that the contextmenu event is fired without
changing any of the code that triggers the XUL popup. However, some changes
were needed to have the widget code ignore the synthetic mouse events that
the Windows platform sends us, because those would otherwise immediately
dismiss the contextmenu popup after it appeared.
MozReview-Commit-ID: 9HFZLC6xUAi
--HG--
extra : rebase_source : aea932d9f95454c585bcdf962d151c946b5c6ec2
The new test failure is caused by a bug of the test API, KeyboardLayout::SysnthesizeNativeKeyEvent(). It doesn't generate WM_SYSKEY* messages nor WM_SYS*CHAR messages when Alt key is pressed. Therefore, the new path in the previous code works unexpectedly with automated tests.
This patch makes KeyboardLayout::SysnthesizeNativeKeyEvent() WM_SYS* message aware. When Alt key is pressed (but Ctrl key is not pressed) and the Alt key + something doesn't cause text input, the API generates WM_SYS* messages as expected.
MozReview-Commit-ID: FLbe4SYEZLf
--HG--
extra : rebase_source : 054147997eddfb01dbad63afc07e0b4f59a60257
Some keyboard utilities for Windows can change non-printable keys to printable keys. Therefore, if a keydown message is followed by one or more char message whose wParam isn't a control character, NativeKey should treat it as a printable key's event.
MozReview-Commit-ID: HoFbz5Zafeh
--HG--
extra : rebase_source : 9001c58cb082a93946e1b4c445dfe71f15d08997
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : 1c42bb32a662f2659c934a245ecd0025045120a5
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Puts an empty implementation into nsBaseWidget.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : 2a94a47f1e7fe986d1efc3854c72968a3e28e365
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : 82733f682c9e254e20354cc6908955a1e7485ee7
David Anderson
Kartikaya Gupta
Carsten "Tomcat" Book
Masayuki Nakano
Sebastian Hengst
Aaron Klotz
George Wright
Xidorn Quan
Thomas Wisniewski
Nicolas Silva
Nathan Froyd
Makoto Kato
Gerald Squelart
Jonathan Kew
Chih-Yi Leu
Phil Ringnalda
Ho-Pang Hsu
Wes Kocher
Nicholas Nethercote