The new names make it clearer that these actions apply to just one thread.
- profiler_sleep_start() --> profiler_thread_sleep()
- profiler_sleep_end() --> profiler_thread_wake()
- profiler_is_sleeping() --> profiler_thread_is_sleeping()
- GeckoProfilerSleepRAII --> GeckoProfilerThreadSleepRAII
- GeckoProfilerWakeRAII --> GeckoProfilerThreadWakeRAII
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
--HG--
extra : rebase_source : bef5612a933db3211400e9d8bd2848690de2d2e5
Currently, we use alias NS_VK_* for WidgetKeyboardEvent::mKeyCode. Similarly, we should create alias enum for nsIDOMKeyEvent::DOM_KEY_LOCATION_*. Then, we can reduce the length and avoid to include nsIDOMKeyEvent in some cpp files.
MozReview-Commit-ID: 5cs4zQ061Lc
--HG--
extra : rebase_source : e6a6edd27718b9e3d4a40b07902d029791876999
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
--HG--
extra : rebase_source : a1badc205a99efd803de624d24b69e911f81d308
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
--HG--
extra : rebase_source : 15559e62882f97d5062703e2308fa1c22016f340
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
--HG--
extra : rebase_source : 2ad588d0513741ff6a58be6f523cf59d8deea151
Sylvestre Ledru
Carsten "Tomcat" Book
Chris Peterson
Nicholas Nethercote
Wes Kocher
David Major
David Anderson
Benjamin Smedberg
Jeff Walden
Daniel Holbert
Randall Barker
Kartikaya Gupta
Mantaroh Yoshinaga
Stone Shih
Emanuel Hoogeveen
Ryan Hunt
Masayuki Nakano
Cameron McCormack
Tracy Walker
Masatoshi Kimura
Tim Huang