The fixup migration assumes that there must be a default panel, and sets the history panel as default if not.
This assumption is wrong in the case where no panels are visible: in this case there is no default.
Before this commit, that migration will make the history panel visible for all users who had no
visible panels, with this commit that migration will retain the all-panels-hidden state.
Note: it's impossible for us to recover the all-panels-hidden state for clients that have already
run the migration, however we can at least prevent this issue from happening for users who
have not yet migrated (i.e. in release).
MozReview-Commit-ID: 9JlmltPW2Ly
--HG--
extra : rebase_source : 4e608910775c971ec09c0f9096b8ae36e9f7b877
Now, NativeKey::HandleCharMessage() has almost same code, one is for dispatching eKeyPress event for non-printable keys or printable keys when one of Alt or Ctrl key is pressed, the other is for printable keys when Alt or Ctrl key is pressed.
The difference of them is, the former block removes Alt state and Ctrl state for handling AltGr key. When AltGr key is pressed, both Alt and Ctrl state are true. However, EditorBase treas keypress events whose altKey or ctrlKey is true as non-printable key event. Therefore, we need to set these modifier state to false when AltGr key is pressed and the key causes some text.
Note that as far as we know, when a key press with AltGr doesn't cause any characters, WM_CHAR isn't generated. Therefore, we don't need to check with complicated logic if the key event is actually inputting a character.
MozReview-Commit-ID: BRNWfICvkSm
--HG--
extra : rebase_source : 3b8a2aaeb4c53be1567f7a8d17dfef1af90406dd
Current shortcut key handling is really difference from what we did before struggling with "key hell". Therefore, remaining hacks for charCode in NativeKey::HandleCharMessage() are not necessary because they are for old code.
MozReview-Commit-ID: 3hvsBOiJ6VV
--HG--
extra : rebase_source : 7387fc89930f9b15d5d01612eb4a7a5726924bcd
This patch makes NativeKey::HandleCharMessage() stop dispatching eKeyPress event when the message is inputting a control character. NativeKey::HandleCharMessage() runs following cases:
1. WM_KEYDOWN followed by a WM_CHAR message whose wParam is not a control character causes inputting printable characters.
2. WM_CHAR message is received without WM_KEYDOWN message.
So, when HandleCharMessage() is called for a control character, it's unusual case. E.g., another application sends only WM_CHAR message with a control character.
On the other hand, Gecko is the only browser which dispatches "keypress" event even if pressed printable key doesn't cause inputting any characters. And such "keypress" event is used for shortcut key handling and some default action handling. So, even if we stop dispatching eKeyPress event from HandleCharMessage(), it shouldn't affect most users.
Note that this patch does NOT change the behavior when the user inputs a control character with usual keyboard layout such as Ctrl+A of en-US keyboard layout because DispatchKeyPressEventsWithoutCharMessage() dispatches eKeyPress event in such cases.
This patch also adds a lot of tests with Ctrl or Alt state for detecting regressions.
MozReview-Commit-ID: KUNqTp7RDSc
--HG--
extra : rebase_source : f91e37b0b82a8e8a95444a08f6d3101f14fadc50
- Added `addDeviceForTest` that removes automatically the device added at the
end of the test.
- Improved `switchDevice` with more assertions.
MozReview-Commit-ID: D1BJozD65uj
Carsten "Tomcat" Book
Rajat garg
Valentin Gosu
Kan-Ru Chen
Jon Coppeard
Gabriel Luong
Wes Kocher
Brian Grinstead
Lin Clark
Gary Kwong
Kartikaya Gupta
Randell Jesup
Georg Fritzsche
Sebastian Hengst
Andrzej Hunt
Tom Schuster
Kilik Kuo
Masayuki Nakano
Patrick Brosset
Julian Descottes
Tim Huang
Matteo Ferretti
Phil Ringnalda
Franziskus Kiefer
Dimi Lee