searching for reviewer(m_kato)
bdce123aa2c2aeb4ccd3848a961fbfd97b6d0ec7: Bug 1347835 - NativeKey should dispatch keypress events even if WM_KEYDOWN is processed by IME but followed by printable WM_(SYS)CHAR messages. r=m_kato, a=gchang
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 10 Apr 2017 15:32:02 +0900 - rev 375943
Push 11063 by ryanvm@gmail.com at Mon, 17 Apr 2017 14:39:33 +0000
Bug 1347835 - NativeKey should dispatch keypress events even if WM_KEYDOWN is processed by IME but followed by printable WM_(SYS)CHAR messages. r=m_kato, a=gchang Some IME may handle WM_KEYDOWN message before application and may set the keycode value to VK_PROCSSKEY but not do actually. Similarly, IME may handle WM_KEYDOWN message and replace following WM_CHAR messages with different characters. Therefore, even if WM_KEYDOWN message comes with VK_PROCESSKEY, NativeKey shouldn't stop dispatching keypress events if it detects following printable char messages. MozReview-Commit-ID: DcC2qgcLDrQ
31a1c091957eaf1ab20472fd4afc037eed7f819d: Bug 1346499 Don't remove Ctrl nor Alt modifier state at dispatching eKeyPress event when the modifier doesn't change inputting character r=m_kato a=gchang
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 14 Mar 2017 00:32:50 +0900 - rev 375379
Push 10935 by cbook@mozilla.com at Thu, 23 Mar 2017 11:06:14 +0000
Bug 1346499 Don't remove Ctrl nor Alt modifier state at dispatching eKeyPress event when the modifier doesn't change inputting character r=m_kato a=gchang Ctrl+Space causes WM_CHAR of ' '. On the other native applications, you can input ' ' with this key combination though, we shouldn't allow this because we need to remove Ctrl and Alt modifier state at dispatching keypress event for the limitation of TextEditor but this is important key combination for custom shortcut keys. So, when Ctrl or Alt key is pressed but it doesn't change the inputting character, i.e., the character can be inputted without Ctrl or Alt, we shouldn't remove those modifier state from eKeyPress event. MozReview-Commit-ID: 7omLvNdQWzW
439f5e4ed073c9bc4e1dbc8d0f719e57ef6b1136: Bug 1342753 - Use app locale in DateTimeFormat.cpp, instead of OS locale. r=m_kato
Zibi Braniecki <gandalf@mozilla.com> - Mon, 27 Feb 2017 09:36:50 -0800 - rev 374925
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1342753 - Use app locale in DateTimeFormat.cpp, instead of OS locale. r=m_kato MozReview-Commit-ID: SPsNYxe493
f89a27e84f5e2daa606d23d0721977afb4e0cb77: Bug 1341986 - Add default font prefs for Arabic on Android, to try and avoid fallback finding broken fonts. r=m_kato
Jonathan Kew <jkew@mozilla.com> - Thu, 02 Mar 2017 12:14:18 +0000 - rev 374645
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1341986 - Add default font prefs for Arabic on Android, to try and avoid fallback finding broken fonts. r=m_kato
c3563703a34d21d9442654503b15a97795868e42: Bug 1343446 NativeKey::GetFollowingCharMessage() should ignore found message if PeekMessage(PM_REMOVE) retrieves different char message but the found odd char message was odd r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 01 Mar 2017 14:48:05 +0900 - rev 374587
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1343446 NativeKey::GetFollowingCharMessage() should ignore found message if PeekMessage(PM_REMOVE) retrieves different char message but the found odd char message was odd r=m_kato According to crash reports, we may find WM_CHAR whose wParam is 0 and scancode is 0xFF with a call of PeekMessage(PM_NOREMOVE) but we'll remove usual char message with a call of PeekMessage(PM_REMOVE). In such case, we should ignore the found odd message and take the usual char message which was removed from the queue actually. MozReview-Commit-ID: Gw8LvCXxul
3bee9644cf4c29e69708ddca242b976ee95ad194: Bug 1342865 When Control key is pressed and InsertText() isn't called on macOS, its KeyboardEvent.key value should be characters which are inputted by the key without Control key state r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 01 Mar 2017 10:58:55 +0900 - rev 374536
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1342865 When Control key is pressed and InsertText() isn't called on macOS, its KeyboardEvent.key value should be characters which are inputted by the key without Control key state r=m_kato Because of conforming to UI Events KeyboardEvent key Values, when some modifier keys cause not inputting character, the KeyboardEvent.key value should be computed with removing all modifier state except glyph modifier keys. When Control key is pressed, Cocoa fires odd key events typically. For example, characters isn't computed with same logic of UI Events KeyboardEvent key Values especially when Option key is pressed (see adding testcases for the detail). Therefore, this patch makes TISInputSourceWrapper::InitKeyEvent() ignore both characters and charactersIgnoringModifiers at computing KeyboardEvent.key value when Control key is pressed and InsertText() isn't called. On the other hand, this patch does NOT touch the path to compute KeyboardEvent.key when Command key is pressed. It should be changed in different bug because Command key behavior isn't so simple. MozReview-Commit-ID: dMHgUEOnQw
ec52c7c8c6f18b8558be0525c14e09c8b26dd74c: Bug 1342787 - Use Nirmala UI as fallback font for additional Indic script blocks. r=m_kato
Jonathan Kew <jkew@mozilla.com> - Tue, 28 Feb 2017 09:23:09 +0000 - rev 374250
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1342787 - Use Nirmala UI as fallback font for additional Indic script blocks. r=m_kato
6168ec4ebde4b44d2b2f4798ba493e0661e0e392: Bug 1342841 - Use Leelawadi UI as fallback for more scripts than just Thai, as it has additional character support. r=m_kato
Jonathan Kew <jkew@mozilla.com> - Tue, 28 Feb 2017 09:23:05 +0000 - rev 374249
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1342841 - Use Leelawadi UI as fallback for more scripts than just Thai, as it has additional character support. r=m_kato
51b368d536a3b1ae2985dcd0bc8414cd2d2cec66: Bug 1263302 Swap kVK_ISO_Section and kVK_ANSI_Grave key code values of ISO keyboard at computing KeyboardEvent.code value because macOS sends them as swapped r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 27 Feb 2017 18:04:30 +0900 - rev 374232
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1263302 Swap kVK_ISO_Section and kVK_ANSI_Grave key code values of ISO keyboard at computing KeyboardEvent.code value because macOS sends them as swapped r=m_kato macOS oddly sends kVK_ISO_Section instead of kVK_ANSI_Grave when user types left key of Key1 only when the connected keyboard is ISO keyboard. On the other hand, macOS sends kVK_ANSI_Grave instead of kVK_ISO_Section when user types left key of KeyZ only when the connected keyboard is ISO keyboard. So, macOS swapps their key code values only when ISO keyboard is connected. So, we should treat them as swapped when we compute KeyboardEvent.code value since Chromium treates them as swapped only when computing KeyboardEvent.code value too. MozReview-Commit-ID: BYeFedydyR5
0a0ad749ef253283e2288b5bcac8ea7a06b16eed: Bug 1341960 TextInputHandler shouldn't ignore InsertText() calls even if TextInputHandler has already dispatched keypress events and/or composition events for the key down but InsertText() is called again for inserting printable text r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 23 Feb 2017 11:45:13 +0900 - rev 373576
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1341960 TextInputHandler shouldn't ignore InsertText() calls even if TextInputHandler has already dispatched keypress events and/or composition events for the key down but InsertText() is called again for inserting printable text r=m_kato Korean IME and some other simple IME may not use marked text at composing text. Such IME modifies composing character with InsertText() with aReplacementRange. Then, when user types new character, such IME may replace the previous character with a call of InsertText() with aReplacementRange and insert the next character with additional call of InsertText() without aReplacementRange. In this case, InsertText() ignores the call when the native keydown event is already caused composition events. However, we need to allow to dispatch keypress event for supporting to insert text even in such case. This patch checks if inserting text is printable. If it's not a printable character such as U+000A at pressing Enter, keeping current behavior. Otherwise, dispatching keypress event instead. MozReview-Commit-ID: 5NcCgXfvniO
5f246ac3d663c84fae5e5c07535c4df55f96a0ea: Bug 1338451 Editor should commit composition first at handling mousedown event r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 10 Feb 2017 16:51:59 +0900 - rev 372013
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1338451 Editor should commit composition first at handling mousedown event r=m_kato Editor may need to create some new transaction during handling a mousedown event. Therefore, editor needs to finish pending composition transaction. So, mousedown event handler should commit composition first. MozReview-Commit-ID: 2BaoYwB7wLS
9aeb203f8d6f4dede99451a5228547eddc47185a: Bug 1338758 - Handle success codes from nsIUnicodeDecoder in nsTextToSubURI::UnEscapeNonAsciiURI. r=m_kato
Masatoshi Kimura <VYV03354@nifty.ne.jp> - Sat, 11 Feb 2017 20:40:58 +0900 - rev 371531
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1338758 - Handle success codes from nsIUnicodeDecoder in nsTextToSubURI::UnEscapeNonAsciiURI. r=m_kato MozReview-Commit-ID: 43jAOFPYMeT
367692beef13216212dccaa48505150ad1b930f2: Bug 1338553 - Fix missing include in WinUtils. r=m_kato
Emanuel Hoogeveen <emanuel.hoogeveen@gmail.com> - Sat, 11 Feb 2017 18:36:52 +0800 - rev 371427
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1338553 - Fix missing include in WinUtils. r=m_kato MozReview-Commit-ID: FeOIHBLMcRe
3f4ac53f22253afe6acb8aab2bec9a664ce7feba: Bug 1337718 part.10 Make EditorEventListener::MouseClick() and EditorEventListener::HandleMiddleClickPaste() use WidgetMouseEvent as far as possible r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 08 Feb 2017 22:55:54 +0900 - rev 370789
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1337718 part.10 Make EditorEventListener::MouseClick() and EditorEventListener::HandleMiddleClickPaste() use WidgetMouseEvent as far as possible r=m_kato MozReview-Commit-ID: EMFevpq9ftM
942fedc10653157bb1c5997527b83cef67a7d388: Bug 1337718 part.9 Make IMEStateManager::OnClickInEditor() take const WidgetMouseEvent* instead of nsIDOMMouseEvent* r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 08 Feb 2017 22:29:14 +0900 - rev 370788
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1337718 part.9 Make IMEStateManager::OnClickInEditor() take const WidgetMouseEvent* instead of nsIDOMMouseEvent* r=m_kato MozReview-Commit-ID: KdoMcxW8lkT
e1f009677c72a18d53cc98f37af6ed01255b015c: Bug 1337718 part.8 Make EditorEventListener::NotifyIMEOfMouseButtonEvent() take WidgetMouseEvent* instead of nsIDOMMouseEvent* r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 08 Feb 2017 22:19:14 +0900 - rev 370787
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1337718 part.8 Make EditorEventListener::NotifyIMEOfMouseButtonEvent() take WidgetMouseEvent* instead of nsIDOMMouseEvent* r=m_kato MozReview-Commit-ID: A53lxmDXLMb
b8fb46941569d2e0f2dfd584d18e944614db68af: Bug 1337718 part.7 Make IMEStateManager::OnMouseButtonEventInEditor() take WidgetMouseEvent* instead of nsIDOMMouseEvent r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 08 Feb 2017 22:02:49 +0900 - rev 370786
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1337718 part.7 Make IMEStateManager::OnMouseButtonEventInEditor() take WidgetMouseEvent* instead of nsIDOMMouseEvent r=m_kato MozReview-Commit-ID: FDselwSymZq
b12925eebad7bde51fc9c35725ecec4fdf18db0b: Bug 1337718 part.6 Make EditorEventListener::KeyDown() take const WidgetKeyboardEvent* instead of nsIDOMKeyEvent* r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 08 Feb 2017 21:30:27 +0900 - rev 370785
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1337718 part.6 Make EditorEventListener::KeyDown() take const WidgetKeyboardEvent* instead of nsIDOMKeyEvent* r=m_kato MozReview-Commit-ID: 6gST8uULwSb
f49e57b87a0bd625b3382dd7f88601d911e6901a: Bug 1337718 part.5 Make IsCtrlShiftPressed() take const WidgetKeyboardEvent* instead of nsIDOMKeyEvent* r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 08 Feb 2017 20:05:12 +0900 - rev 370784
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1337718 part.5 Make IsCtrlShiftPressed() take const WidgetKeyboardEvent* instead of nsIDOMKeyEvent* r=m_kato Additionally, this patch removes unnecessary name space wrapper of IsCtrlShiftPressed(). Perhaps, it was necessary when mozilla::EditorEventListener was nsEditorEventListener. MozReview-Commit-ID: EHzt7aRtYgQ
51f5c75cfb6e38fbea59a5693b9d4d9984280c12: Bug 1337718 part.4 Make EditorEventListener::KeyUp() take const WidgetKeyboardEvent* instead of nsIDOMKeyEvent* r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 08 Feb 2017 20:22:57 +0900 - rev 370783
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1337718 part.4 Make EditorEventListener::KeyUp() take const WidgetKeyboardEvent* instead of nsIDOMKeyEvent* r=m_kato MozReview-Commit-ID: K9zCJsYgfbL
331fad29a7c4f735861f5130be935cba0307c730: Bug 1337718 part.3 Make EditorEventListener::KeyPress() take WidgetKeyboardEvent* instead of nsIDOMKeyEvent* r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 08 Feb 2017 19:50:50 +0900 - rev 370782
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1337718 part.3 Make EditorEventListener::KeyPress() take WidgetKeyboardEvent* instead of nsIDOMKeyEvent* r=m_kato MozReview-Commit-ID: 49fcZXPSsQ4
a07723fd11f17a9446cfb1626c17b9acc5657b7f: Bug 1337718 part.2 Make EditorEventListener::ShouldHandleNativeKeyBindings() take WidgetKeyboardEvent* instead of nsIDOMKeyEvent* r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 08 Feb 2017 19:47:05 +0900 - rev 370781
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1337718 part.2 Make EditorEventListener::ShouldHandleNativeKeyBindings() take WidgetKeyboardEvent* instead of nsIDOMKeyEvent* r=m_kato MozReview-Commit-ID: 4JS2yJ6iXgY
2888f135c73709ed5e1582c55cdab2eee9c8d3be: Bug 1337718 part.1 Make EditorBase::HandleKeyPressEvent() take WidgetKeyboardEvent* instead of nsIDOMKeyEvent* r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 08 Feb 2017 20:18:17 +0900 - rev 370780
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1337718 part.1 Make EditorBase::HandleKeyPressEvent() take WidgetKeyboardEvent* instead of nsIDOMKeyEvent* r=m_kato MozReview-Commit-ID: 8QUiHPRf9AH
64b970234605f682457ada10cd523608861d6864: Bug 1334594 Call NSTextInputClient's insertText:replacementRange: instead of NSTextInput's insertText: from IMEInputHandler::SendCommittedText() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 07 Feb 2017 19:03:14 +0900 - rev 370304
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1334594 Call NSTextInputClient's insertText:replacementRange: instead of NSTextInput's insertText: from IMEInputHandler::SendCommittedText() r=m_kato Bug 1180564 dropped NSTextInput protocl implementation from ChildView but IMEInputHandler::SendCommittedText() still calls it via mView. Therefore, it fails to commit composition in widget level. Instead, we it should call insertText:replacementRange: of NSTextInputClient protocol. Additionally, this patch adds a last resort path. If calling insertText:replacementRange: didn't commit composition in widget level, it calls TextInputHandler::InsertText() directly. MozReview-Commit-ID: BZZypBqC0Mx
3504f8cdd850178af9a2f2a5a1361a8e347a87e6: Bug 1336331 NativeKey::GetFollowingCharMessage() should try to use GetMessage() when PeekMessage() failed to remove a char message from the queue and there is still existing a char message r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 03 Feb 2017 18:01:33 +0900 - rev 369902
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1336331 NativeKey::GetFollowingCharMessage() should try to use GetMessage() when PeekMessage() failed to remove a char message from the queue and there is still existing a char message r=m_kato I think that when PeekMessage(PM_REMOVE) failed to remove a char message but next key message is still a char message, it may be possible that the odd keyboard layout or utility hook only PeekMessage(PM_NOREMOVE) and GetMessage(). If so, we can explain what occurs in this case. I'm still not sure this fixes the case of bug 1336322 comment 0, but we should try to do this because I don't have better idea. MozReview-Commit-ID: CxoO24n167t
21f71652e49132a779ceccba50f92765a38154c1: Bug 1336322 NativeKey::GetFollowingCharMessage() should treat the char message has gone if PeekMessage() failed to remove found char message and next key message becomes non-char message or different key's char message r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 03 Feb 2017 14:30:22 +0900 - rev 369900
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1336322 NativeKey::GetFollowingCharMessage() should treat the char message has gone if PeekMessage() failed to remove found char message and next key message becomes non-char message or different key's char message r=m_kato This patch depends on bug 1336080. When PeekMessage() fails to remove found char message, NativeKey::GetFollowingCharMessage() tries to check next key message in the queue again. Then, when next key message becomes non-char message, such as WM_KEYDOWN or WM_KEYUP, the char message must be removed by odd keyboard layout or something. Similarly, when next key message is a char message but it's caused by different key, the found char message must be removed by one of them too. So, in these cases, NativeKey::GetFollowingCharMessage() should treat the key operation is already handled or canceled by the odd keyboard layout or somebody else. Additionally, in the latter case, following char message should be handled as orphan char message(s) as usual. MozReview-Commit-ID: 8ahs8I0HUQ2
e37b1547760353cd23ef7467c9e77389307bafa8: Bug 1336080 When NativeKey::GetFollowingCharMessage() founds different message when it fails to remove a found char message, it should retry to remove the newly found message if it's caused by same physical key r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 02 Feb 2017 23:26:45 +0900 - rev 369898
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1336080 When NativeKey::GetFollowingCharMessage() founds different message when it fails to remove a found char message, it should retry to remove the newly found message if it's caused by same physical key r=m_kato When NativeKey::GetFollowingCharMessage() tries to remove a char message from the queue, the message might be changed by odd keyboard layout or something. In such case, if the new char message is also caused by same physical key, the char message must be overwritten. Then, we should take the new char message instead. Note that this patch saves original found char message into kFoundCharMsg and it's logged by each points for indicating if this case has occurred. MozReview-Commit-ID: HAduq8sfwFt
b3d2a4cdecd15085d59d2d5fc7661392fb771787: Bug 1336028 NativeKey::GetFollowingCharMessage() should take newer char message when found char message and removed message from the queue is different but their scancode indicates same physical key r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 02 Feb 2017 23:28:48 +0900 - rev 361377
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1336028 NativeKey::GetFollowingCharMessage() should take newer char message when found char message and removed message from the queue is different but their scancode indicates same physical key r=m_kato NativeKey::GetFollowingCharMessage() may remove a char message which is different from previously found message in the queue because hacky keyboard layout or utility can overwrite the wParam when it's removed from the queue. Now, we should assume that newer message, i.e., actually removed from the queue, is the expected message by the user. See bug 1336028 comment 0 for the actual scenarios which are collected by crash reports. https://bugzilla.mozilla.org/show_bug.cgi?id=1336028#c0 MozReview-Commit-ID: 9ZgukHH1vfi
5d641acb1f4ec08ea58ac83cd1359db19176a270: Bug 1335670 NativeKey should dispatch consumed keydown event when it receives WM_NULL at removing WM_*CHAR from the queue and the original message has gone r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 02 Feb 2017 22:43:20 +0900 - rev 361371
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1335670 NativeKey should dispatch consumed keydown event when it receives WM_NULL at removing WM_*CHAR from the queue and the original message has gone r=m_kato Currently, NativeKey::GetFollowingCharMessage() tries 5 times to remove found char message from the queue. It was enough when we found this issue at developing Metrofox. However, this hack is not enough for some odd keyboard layouts because we see some crash reports which gives up to remove a char message from the queue because 5 WM_NULL messages are returned. For preventing this crash, we should check if there is the message which is trying to remove from the queue when NativeKey receives WM_NULL. Then, when there is no key message in the queue or next key message becomes non-char message,, NativeKey should dispatch consumed keydown event because we can assume that the key operation may have already been handled or canceled. Otherwise, NativeKey should retry to remove the message again (until 50 times!, it's just enough big magic number, there is no concrete reason). MozReview-Commit-ID: 1c6Y4OoQdrP
0eb11a6b2075d63080f8f44a69859a4216080cfe: Bug 1334947 Treat a keydown event as inputting empty text if following char message has gone and gets WM_NULL message at calling PeekMessage() for removing a found char message r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 30 Jan 2017 15:43:09 +0900 - rev 361103
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1334947 Treat a keydown event as inputting empty text if following char message has gone and gets WM_NULL message at calling PeekMessage() for removing a found char message r=m_kato There are still a lot of crash due to failing to get following WM_CHAR message. Almost half of them are, we found a WM_CHAR message but it's gone at removing the message from the queue. Although, we're still not sure what happen actually. It could be possible if somebody hooks PeekMessage() or something. Then, we can assume that the found message isn't necessary for the user because it must be removed by somebody when it became unnecessary or is handled. This patch mark a new bool flag, mCharMessageHasGone, as true in such case. Then, NativeKey will dispatch keypress events without following char messages and mark the event as consumed. MozReview-Commit-ID: mporX1sihC
be78084e5b72d1f118dc9419a0303072d6cd9ae0: Bug 1335306 Append active keyboard layout information into crash report when NativeKey crashes due to detecting impossible case caused by 3rd party's keyboard layout or utils r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 31 Jan 2017 23:23:06 +0900 - rev 360932
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1335306 Append active keyboard layout information into crash report when NativeKey crashes due to detecting impossible case caused by 3rd party's keyboard layout or utils r=m_kato When NativeKey crashes by itself, it means that we detect an impossible situation in usual environment. In such case, active 3rd party's keyboard layout or something other utility may hook API and returns odd result to us. For investigating the cause and deciding what we should do in such cases, we should collect active keyboard layout name via crash reports. MozReview-Commit-ID: HYRj24GwDHZ
781883ac1d342a1f045a7bb9f79ef9452471c28b: Bug 1321230 - Remove legacy generator from widget/. r=m_kato
Tooru Fujisawa <arai_a@mac.com> - Sat, 28 Jan 2017 00:42:47 +0900 - rev 360522
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1321230 - Remove legacy generator from widget/. r=m_kato
a321a80847c9758609d098266d7869aa76a6f226: Bug 1333451 - add BUG_COMPONENT to intl/* files. r=m_kato
Joel Maher <jmaher@mozilla.com> - Fri, 27 Jan 2017 08:18:44 -0500 - rev 360510
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1333451 - add BUG_COMPONENT to intl/* files. r=m_kato MozReview-Commit-ID: 8azgwps19Ep
4daf122b00ce9084b6c1f31d8e3e29d40d393ad3: Bug 1333451 - add BUG_COMPONENT to intl/* files. r=m_kato
Joel Maher <jmaher@mozilla.com> - Thu, 26 Jan 2017 05:51:56 -0500 - rev 360260
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1333451 - add BUG_COMPONENT to intl/* files. r=m_kato MozReview-Commit-ID: 2yGHs5QaZzQ
b71eda2d078a990763e14e29f3dad757b6426441: Bug 1343446 - NativeKey::GetFollowingCharMessage() should ignore found message if PeekMessage(PM_REMOVE) retrieves different char message but the found odd char message was odd. r=m_kato, a=lizzard
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 01 Mar 2017 14:48:05 +0900 - rev 359640
Push 10854 by ryanvm@gmail.com at Sat, 04 Mar 2017 00:19:51 +0000
Bug 1343446 - NativeKey::GetFollowingCharMessage() should ignore found message if PeekMessage(PM_REMOVE) retrieves different char message but the found odd char message was odd. r=m_kato, a=lizzard According to crash reports, we may find WM_CHAR whose wParam is 0 and scancode is 0xFF with a call of PeekMessage(PM_NOREMOVE) but we'll remove usual char message with a call of PeekMessage(PM_REMOVE). In such case, we should ignore the found odd message and take the usual char message which was removed from the queue actually. MozReview-Commit-ID: Gw8LvCXxul
6ba5938db9d24be0322236bd6ddd63a116f66152: Bug 1342787 - Use Nirmala UI as fallback font for additional Indic script blocks. r=m_kato, a=lizzard
Jonathan Kew <jkew@mozilla.com> - Tue, 28 Feb 2017 09:23:09 +0000 - rev 359634
Push 10854 by ryanvm@gmail.com at Sat, 04 Mar 2017 00:19:51 +0000
Bug 1342787 - Use Nirmala UI as fallback font for additional Indic script blocks. r=m_kato, a=lizzard
5fd05d2d980957d2657b68de28e0242f2deb12d7: Bug 1341986 - Add default font prefs for Arabic on Android, to try and avoid fallback finding broken fonts. r=m_kato, a=lizzard
Jonathan Kew <jkew@mozilla.com> - Thu, 02 Mar 2017 12:14:18 +0000 - rev 359630
Push 10853 by ryanvm@gmail.com at Fri, 03 Mar 2017 21:57:32 +0000
Bug 1341986 - Add default font prefs for Arabic on Android, to try and avoid fallback finding broken fonts. r=m_kato, a=lizzard
5b0acf90608b98543f31b06b3f145ba49e39d50e: Bug 1341960 TextInputHandler shouldn't ignore InsertText() calls even if TextInputHandler has already dispatched keypress events and/or composition events for the key down but InsertText() is called again for inserting printable text r=m_kato a=gchang
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 23 Feb 2017 11:45:13 +0900 - rev 359599
Push 10843 by cbook@mozilla.com at Fri, 03 Mar 2017 14:51:01 +0000
Bug 1341960 TextInputHandler shouldn't ignore InsertText() calls even if TextInputHandler has already dispatched keypress events and/or composition events for the key down but InsertText() is called again for inserting printable text r=m_kato a=gchang Korean IME and some other simple IME may not use marked text at composing text. Such IME modifies composing character with InsertText() with aReplacementRange. Then, when user types new character, such IME may replace the previous character with a call of InsertText() with aReplacementRange and insert the next character with additional call of InsertText() without aReplacementRange. In this case, InsertText() ignores the call when the native keydown event is already caused composition events. However, we need to allow to dispatch keypress event for supporting to insert text even in such case. This patch checks if inserting text is printable. If it's not a printable character such as U+000A at pressing Enter, keeping current behavior. Otherwise, dispatching keypress event instead. MozReview-Commit-ID: 5NcCgXfvniO
7363ef4a20e5d3ee808aa3f1eaa15254d01a16c2: Bug 1342841 - Use Leelawadi UI as fallback for more scripts than just Thai, as it has additional character support. r=m_kato, a=gchang
Jonathan Kew <jkew@mozilla.com> - Tue, 28 Feb 2017 09:23:05 +0000 - rev 359578
Push 10832 by ryanvm@gmail.com at Thu, 02 Mar 2017 12:43:01 +0000
Bug 1342841 - Use Leelawadi UI as fallback for more scripts than just Thai, as it has additional character support. r=m_kato, a=gchang
64915a68d19056e45c4c1ad1bd75593fdbb8b4c7: Bug 1338758 - Handle success codes from nsIUnicodeDecoder in nsTextToSubURI::UnEscapeNonAsciiURI. r=m_kato a=jcristau
Masatoshi Kimura <VYV03354@nifty.ne.jp> - Sat, 11 Feb 2017 20:40:58 +0900 - rev 359174
Push 10733 by cbook@mozilla.com at Tue, 14 Feb 2017 14:40:23 +0000
Bug 1338758 - Handle success codes from nsIUnicodeDecoder in nsTextToSubURI::UnEscapeNonAsciiURI. r=m_kato a=jcristau MozReview-Commit-ID: 43jAOFPYMeT
8ee7930272cb4e486f7f6b926ea9837a9d5ca0de: Bug 1334594 - Call NSTextInputClient's insertText:replacementRange: instead of NSTextInput's insertText: from IMEInputHandler::SendCommittedText(). r=m_kato, a=jcristau
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 07 Feb 2017 19:03:14 +0900 - rev 359116
Push 10719 by ryanvm@gmail.com at Fri, 10 Feb 2017 20:12:01 +0000
Bug 1334594 - Call NSTextInputClient's insertText:replacementRange: instead of NSTextInput's insertText: from IMEInputHandler::SendCommittedText(). r=m_kato, a=jcristau Bug 1180564 dropped NSTextInput protocl implementation from ChildView but IMEInputHandler::SendCommittedText() still calls it via mView. Therefore, it fails to commit composition in widget level. Instead, we it should call insertText:replacementRange: of NSTextInputClient protocol. Additionally, this patch adds a last resort path. If calling insertText:replacementRange: didn't commit composition in widget level, it calls TextInputHandler::InsertText() directly. MozReview-Commit-ID: BZZypBqC0Mx
05fae22830c0365b8173be4a2584ff0375b547a1: Bug 1336331 - NativeKey::GetFollowingCharMessage() should try to use GetMessage() when PeekMessage() failed to remove a char message from the queue and there is still existing a char message. r=m_kato, a=jcristau
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 03 Feb 2017 18:01:33 +0900 - rev 358968
Push 10691 by ryanvm@gmail.com at Mon, 06 Feb 2017 18:14:22 +0000
Bug 1336331 - NativeKey::GetFollowingCharMessage() should try to use GetMessage() when PeekMessage() failed to remove a char message from the queue and there is still existing a char message. r=m_kato, a=jcristau I think that when PeekMessage(PM_REMOVE) failed to remove a char message but next key message is still a char message, it may be possible that the odd keyboard layout or utility hook only PeekMessage(PM_NOREMOVE) and GetMessage(). If so, we can explain what occurs in this case. I'm still not sure this fixes the case of bug 1336322 comment 0, but we should try to do this because I don't have better idea. MozReview-Commit-ID: CxoO24n167t
ee21650b00374a2363f08866dff5f64cbcce63ce: Bug 1336322 - NativeKey::GetFollowingCharMessage() should treat the char message has gone if PeekMessage() failed to remove found char message and next key message becomes non-char message or different key's char message. r=m_kato, a=jcristau
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 03 Feb 2017 14:30:22 +0900 - rev 358967
Push 10691 by ryanvm@gmail.com at Mon, 06 Feb 2017 18:14:22 +0000
Bug 1336322 - NativeKey::GetFollowingCharMessage() should treat the char message has gone if PeekMessage() failed to remove found char message and next key message becomes non-char message or different key's char message. r=m_kato, a=jcristau This patch depends on bug 1336080. When PeekMessage() fails to remove found char message, NativeKey::GetFollowingCharMessage() tries to check next key message in the queue again. Then, when next key message becomes non-char message, such as WM_KEYDOWN or WM_KEYUP, the char message must be removed by odd keyboard layout or something. Similarly, when next key message is a char message but it's caused by different key, the found char message must be removed by one of them too. So, in these cases, NativeKey::GetFollowingCharMessage() should treat the key operation is already handled or canceled by the odd keyboard layout or somebody else. Additionally, in the latter case, following char message should be handled as orphan char message(s) as usual. MozReview-Commit-ID: 8ahs8I0HUQ2
4c3463d88059615faf6cc4ff55b792d699d79c1c: Bug 1336080 - When NativeKey::GetFollowingCharMessage() founds different message when it fails to remove a found char message, it should retry to remove the newly found message if it's caused by same physical key. r=m_kato, a=jcristau
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 02 Feb 2017 23:26:45 +0900 - rev 358966
Push 10691 by ryanvm@gmail.com at Mon, 06 Feb 2017 18:14:22 +0000
Bug 1336080 - When NativeKey::GetFollowingCharMessage() founds different message when it fails to remove a found char message, it should retry to remove the newly found message if it's caused by same physical key. r=m_kato, a=jcristau When NativeKey::GetFollowingCharMessage() tries to remove a char message from the queue, the message might be changed by odd keyboard layout or something. In such case, if the new char message is also caused by same physical key, the char message must be overwritten. Then, we should take the new char message instead. Note that this patch saves original found char message into kFoundCharMsg and it's logged by each points for indicating if this case has occurred. MozReview-Commit-ID: HAduq8sfwFt
2fd7a81771a7dd8c4dc47ee6199adac8500cd01f: Bug 1336028 NativeKey::GetFollowingCharMessage() should take newer char message when found char message and removed message from the queue is different but their scancode indicates same physical key r=m_kato a=gchang
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 02 Feb 2017 23:28:48 +0900 - rev 358959
Push 10688 by cbook@mozilla.com at Mon, 06 Feb 2017 15:09:03 +0000
Bug 1336028 NativeKey::GetFollowingCharMessage() should take newer char message when found char message and removed message from the queue is different but their scancode indicates same physical key r=m_kato a=gchang NativeKey::GetFollowingCharMessage() may remove a char message which is different from previously found message in the queue because hacky keyboard layout or utility can overwrite the wParam when it's removed from the queue. Now, we should assume that newer message, i.e., actually removed from the queue, is the expected message by the user. See bug 1336028 comment 0 for the actual scenarios which are collected by crash reports. https://bugzilla.mozilla.org/show_bug.cgi?id=1336028#c0 MozReview-Commit-ID: 9ZgukHH1vfi
673d97776e64b8084064e59bca9cac760b7a11f9: Bug 1335670 NativeKey should dispatch consumed keydown event when it receives WM_NULL at removing WM_*CHAR from the queue and the original message has gone r=m_kato a=gchang
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 02 Feb 2017 22:43:20 +0900 - rev 358957
Push 10688 by cbook@mozilla.com at Mon, 06 Feb 2017 15:09:03 +0000
Bug 1335670 NativeKey should dispatch consumed keydown event when it receives WM_NULL at removing WM_*CHAR from the queue and the original message has gone r=m_kato a=gchang Currently, NativeKey::GetFollowingCharMessage() tries 5 times to remove found char message from the queue. It was enough when we found this issue at developing Metrofox. However, this hack is not enough for some odd keyboard layouts because we see some crash reports which gives up to remove a char message from the queue because 5 WM_NULL messages are returned. For preventing this crash, we should check if there is the message which is trying to remove from the queue when NativeKey receives WM_NULL. Then, when there is no key message in the queue or next key message becomes non-char message,, NativeKey should dispatch consumed keydown event because we can assume that the key operation may have already been handled or canceled. Otherwise, NativeKey should retry to remove the message again (until 50 times!, it's just enough big magic number, there is no concrete reason). MozReview-Commit-ID: 1c6Y4OoQdrP
d4910d723a36c7e49c0a40f0015603aa4c02b8dd: Bug 1334947 Treat a keydown event as inputting empty text if following char message has gone and gets WM_NULL message at calling PeekMessage() for removing a found char message r=m_kato a=gchang
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 30 Jan 2017 15:43:09 +0900 - rev 358952
Push 10688 by cbook@mozilla.com at Mon, 06 Feb 2017 15:09:03 +0000
Bug 1334947 Treat a keydown event as inputting empty text if following char message has gone and gets WM_NULL message at calling PeekMessage() for removing a found char message r=m_kato a=gchang There are still a lot of crash due to failing to get following WM_CHAR message. Almost half of them are, we found a WM_CHAR message but it's gone at removing the message from the queue. Although, we're still not sure what happen actually. It could be possible if somebody hooks PeekMessage() or something. Then, we can assume that the found message isn't necessary for the user because it must be removed by somebody when it became unnecessary or is handled. This patch mark a new bool flag, mCharMessageHasGone, as true in such case. Then, NativeKey will dispatch keypress events without following char messages and mark the event as consumed. MozReview-Commit-ID: mporX1sihC
3c3be02271337ec3d23c4515f2aa7041c8ee4c09: Bug 1335306 Append active keyboard layout information into crash report when NativeKey crashes due to detecting impossible case caused by 3rd party's keyboard layout or utils r=m_kato a=jcristau
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 31 Jan 2017 23:23:06 +0900 - rev 358820
Push 10659 by cbook@mozilla.com at Wed, 01 Feb 2017 14:58:22 +0000
Bug 1335306 Append active keyboard layout information into crash report when NativeKey crashes due to detecting impossible case caused by 3rd party's keyboard layout or utils r=m_kato a=jcristau When NativeKey crashes by itself, it means that we detect an impossible situation in usual environment. In such case, active 3rd party's keyboard layout or something other utility may hook API and returns odd result to us. For investigating the cause and deciding what we should do in such cases, we should collect active keyboard layout name via crash reports. MozReview-Commit-ID: HYRj24GwDHZ
1e031209b4156ef03706bcc2a2fca62a1277a726: Bug 1330402 - add BUG_COMPONENT to editor/* files. r=m_kato
Joel Maher <jmaher@mozilla.com> - Fri, 13 Jan 2017 08:40:24 -0500 - rev 357344
Push 10621 by jlund@mozilla.com at Mon, 23 Jan 2017 16:02:43 +0000
Bug 1330402 - add BUG_COMPONENT to editor/* files. r=m_kato MozReview-Commit-ID: 3VTNcM49BSS
4d651df764664db0b6be181a7da57d8e5435e508: Bug 1322989 - Reftest for uppercasing of Greek disjunctive eta (ή). r=m_kato
Jonathan Kew <jkew@mozilla.com> - Tue, 20 Dec 2016 10:07:32 +0000 - rev 354596
Push 10621 by jlund@mozilla.com at Mon, 23 Jan 2017 16:02:43 +0000
Bug 1322989 - Reftest for uppercasing of Greek disjunctive eta (ή). r=m_kato