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
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
--HG--
extra : rebase_source : c00b86166a345eec18fa2de74698f6e8859364b8
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
--HG--
extra : rebase_source : 563efc0e65c1d400a32cb0ceec94eb56ad0aa1c5
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
--HG--
extra : rebase_source : c8980c7fa019fc3e0f249b4506fa572e81f4a1e8
The machinery for suppressing the displayport during live resizes
was using the Observer service. However, in the case of multiple
browser windows, this meant that all the open browser windows would
have their displayport suppressed if *any* of the browser windows
was being resized. This was mostly ok, as the displayport suppression
would be turned off once the resize ended. However, the code to
kick off a repaint with the unsuppressed displayport would only get
triggered on one of the windows (whichever happened to process the
unsuppress message last).
This patch stops using the Observer service for the implementation
machinery, and instead locates the active TabParent of the relevant
nsWindow, and invokes the displayport suppression directly on that.
This fixes the repainting bug and also avoids unnecessarily
broadcasting the suppression/unsuppression notification to windows
that don't neccessarily need it.
MozReview-Commit-ID: LBHOgOW9KUp
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
--HG--
extra : rebase_source : 5f01c2a3b36179a61dc00eebd4de6f05596d217b
As of bug 1325299, WINVER is always >= 0x0601 (Windows 7).
MozReview-Commit-ID: Hw5FcEdP0os
--HG--
extra : source : 239400b39f806592a621473ac3a6dd79b238e725
