This reverts commit 312ba34b1e.
Revert "Bug 2039903 - Use nsIWidget::NativeModifiers for SynthesizeNativeKeyEvent. r=masayuki,win-reviewers,gstoll"
This reverts commit cdcd922a07.
Revert "Bug 2039903 - Use proper types for PBrowser::SynthesizeNativeMouseEvent. r=masayuki"
This reverts commit 45369938ed.
Revert "Bug 2039903 - Change from nsIWidget::Modifiers to nsIWidget::NativeModifiers. r=masayuki,geckoview-reviewers,win-reviewers,m_kato,gstoll"
This reverts commit 479f174ddb.
Windows 11 25H2 adds new shortcuts to type em and en dashes (Win+Shift+Minus
and Win+Minus respectively), and these weren't working in Firefox.
The problem was that our keyboard code wasn't expecting the Windows
key (also interpreted as the Meta key) to be a modifier that could
result in a keystroke. Adding these cases means everything works as
expected.
I tested this in the URL bar, on a page with an <input> and a <textarea>,
and with a sample page that showed keyup/down/press events, and everything
looked as I expected. I also ran a try build that didn't show anything
concerning: https://treeherder.mozilla.org/jobs?repo=try&revision=e31ce53cb3738e42b06c5ab6c8d1a2c8e80a0a6b
I don't think there's a way we can add a test for this.
Differential Revision: https://phabricator.services.mozilla.com/D270531
This reverts commit 0062ee7423.
Revert "Bug 1983375 - part 1: Define `MOZ_LOG_ONLY_DEBUG` and variants in `Logging.h` and sort it out `GetBoolName` for making it more generic r=emilio,padenot"
This reverts commit b61fa4819b.
In bug 1910287, we made the method accept `WM_DEADCHAR` message whose `wParam`
is `0` as a valid char message. However, it may be different from found dead
char message at least for an Ethiopic Syllable input.
In the case, we found a WM_DEADCHAR whose `wParam` may not be `0`. Then, we
remove the message from the queue. However, the keyboard/IME makes us to
remove a dummy message whose wParam (inputting character) is NULL and scancode
is 0. Finally, the found message keeps staying in the queue. The crash report
comes after we started accepting WM_DEADCHAR with NULL character above.
However, we haven't handled only a part of dead key sequence but the user tried
to input Ethiopic Syllable. Therefore, it's hard to guess that the user starts
using Firefox with the IME at the timing and the the user keeps using Firefox
with unfunctional IME. Perhaps the IME does something different hack for us to
make itself available on Firefox. Therefore, we should just return `false` as
what we did to make the caller give up removing the following messages.
Differential Revision: https://phabricator.services.mozilla.com/D223245
They do it only when given event class is expected one but they don't include
`ePointerEventClass` which is newly used for `eContextMenu` event since
bug 1675847.
Differential Revision: https://phabricator.services.mozilla.com/D219632
Although I don't know why Ergo-L keyboard layout behave differently on my
environment and the reporter's environment. In the reporter's environment,
second dead key press causes `WM_DEADCHAR` with `0` `wParam`. Then,
`GetFollowingCharMessage()` returns `false` so that it's not stored into
`mFollowingCharMsgs`. Then, `NativeKey::IsFollowedByDeadCharMessage()` returns
`false` and `NativeKey::mIsDeadKey` is set to `false`. Therefore, `NativeKey`
dispatches only `eKeyDown` event but whose `.key` is `"g"` rather than
`DeadKey` and finally, fails to call `KeyboardLayout::ActivateDeadKeyState()`.
Therefore the following dead key sequence is not treated as so.
This patch makes it return `true` for such `WM_DEADCHAR` message so that the
`WM_KEYDOWN` message will be treated as a dead key sequence.
Differential Revision: https://phabricator.services.mozilla.com/D219317
When a printable key is pressed with `Alt`, Windows notify us of `WM_SYSKEYDOWN`
and `WM_SYSCHAR`. However, if the builtin IME for inputting a Unicode character
consumes some printable key presses, Windows does not notify us of `WM_SYSCHAR`.
Therefore, if `WM_SYSKEYDOWN` comes without `WM_SYSCHAR`, we should consume
the `eKeyDown` before dispatching the event so that the key press won't be
handled by access key of the menu nor the content.
Differential Revision: https://phabricator.services.mozilla.com/D207956
When a printable key is pressed with `Alt`, Windows notify us of `WM_SYSKEYDOWN`
and `WM_SYSCHAR`. However, if the builtin IME for inputting a Unicode character
consumes some printable key presses, Windows does not notify us of `WM_SYSCHAR`.
Therefore, if `WM_SYSKEYDOWN` comes without `WM_SYSCHAR`, we should consume
the `eKeyDown` before dispatching the event so that the key press won't be
handled by access key of the menu nor the content.
Differential Revision: https://phabricator.services.mozilla.com/D207956
As far as I've tested on Win 11, we can put it off to load it when first needed
of the keyboard layout data. `ToUnicodeEx` API changes the dead key state and
it's called a lot in `KeyboardLayout::LoadLayout`, however, this patch does
not newly call `LoadLayout` after `TranslateMessage` API at least while handling
a key message. Therefore, this should be safe but regressions of this change
could be serious, so this makes it enabled only in early beta and earlier for
now.
Differential Revision: https://phabricator.services.mozilla.com/D200600
As far as I've tested on Win 11, we can put it off to load it when first needed
of the keyboard layout data. `ToUnicodeEx` API changes the dead key state and
it's called a lot in `KeyboardLayout::LoadLayout`, however, this patch does
not newly call `LoadLayout` after `TranslateMessage` API at least while handling
a key message. Therefore, this should be safe but regressions of this change
could be serious, so this makes it enabled only in early beta and earlier for
now.
Differential Revision: https://phabricator.services.mozilla.com/D200600
A lone surrogate should not appear in `DOMString` at least when the attribute
values of events because of ill-formed UTF-16 string.
`TextEventDispatcher` does not handle surrogate pairs correctly. It should not
split surrogate pairs when it sets `KeyboardEvent.key` value for avoiding the
problem in some DOM API wrappers, e.g., Rust-running-as-wasm.
On the other hand, `.charCode` is an unsigned long attribute and web apps
may use `String.fromCharCode(event.charCode)` to convert the input to string,
and unfortunately, `fromCharCode` does not support Unicode character code
points over `0xFFFF`. Therefore, we may need to keep dispatching 2 `keypress`
events per surrogate pair for the backward compatibility.
Therefore, this patch creates 2 prefs. One is for using single-keypress
event model and double-keypress event model. The other is for the latter,
whether `.key` value never has ill-formed UTF-16 or it's allowed.
If using the single-keypress event model --this is compatible with Safari and
Chrome in non-Windows platforms--, one `keypress` event is dispatched for
typing a surrogate pair. Then, its `.charCode` is over `0xFFFF` which can
work with `String.fromCodePoint()` instead of `String.fromCharCode()` and
`.key` value is set to simply the surrogate pair (i.e., its length is 2).
If using the double-keypress event model and disallowing ill-formed UTF-16
--this is the new default behavior for both avoiding ill-formed UTF-16 string
creation and keeping backward compatibility with not-maintained web apps using
`String.fromCharCode`--, 2 `keypress` events are dispatched. `.charCode` for
first one is the code of the high-surrogate, but `.key` is the surrogate pair.
Then, `.charCode` for second one is the low-surrogate and `.key` is empty
string. In this mode, `TextEditor` and `HTMLEditor` ignores the second
`keypress`. Therefore, web apps can cancel it only with the first `keypress`,
but it indicates the `keypress` introduces a surrogate pair with `.key`
attribute.
Otherwise, if using the double-keypress event model and allowing ill-formed
UTF-16 --this is the traditional our behavior and compatible with Chrome in
Windows--, 2 `keypress` events are dispatched with same `.charCode` values as
the previous mode, but first `.key` is the high-surrogate and the other's is
the low surrogate. Therefore, web apps can cancel either one of them or
both of them.
Finally, this patch makes `TextEditor` and `HTMLEditor` handle text input
with `keypress` events properly. Except in the last mode, `beforeinput` and
`input` events are fired once and their `data` values are the surrogate pair.
On the other hand, in the last mode, 2 sets of `beforeinput` and `input` are
fired and their `.data` values has only the surrogate so that ill-formed
UTF-16 values.
Note that this patch also fixes an issue on Windows. Windows may send a high
surrogate and a low surrogate with 2 sets of `WM_KEYDOWN` and `WM_KEYUP` whose
virtual keycode is `VK_PACKET` (typically, this occurs with `SendInput` API).
For handling this correctly, this patch changes `NativeKey` class to make it
just store the high surrogate for the first `WM_KEYDOWN` and `WM_KEYUP` and use
it when it'll receive another `WM_KEYDOWN` for a low surrogate.
Differential Revision: https://phabricator.services.mozilla.com/D182142
There are only 3 places where nsMemory.h is still needed (image/RasterImage.cpp,
gfx/thebes/gfxFT2FontList.cpp, and nsMemory.cpp). Remove the rest.
Differential Revision: https://phabricator.services.mozilla.com/D158213
Tom Schuster