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
Unfortunately, while with MSVC one would use the `I` modifier to format
LPARAM/LONG_PTR, it doesn't work with clang-cl on 32-bits, because
LONG_PTR there is long, but `I` expects an int.
Differential Revision: https://phabricator.services.mozilla.com/D144916
dom/media/platforms/wmf/WMFEncoderModule.cpp(31,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case MediaDataEncoder::CodecType::VP9:
^
dom/media/platforms/wmf/WMFEncoderModule.cpp(31,5): note: insert '[[fallthrough]];' to silence this warning
case MediaDataEncoder::CodecType::VP9:
^
[[fallthrough]];
netwerk/test/gtest/TestNamedPipeService.cpp(212,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
default: // error
^
netwerk/test/gtest/TestNamedPipeService.cpp(212,5): note: insert '[[fallthrough]];' to silence this warning
default: // error
^
[[fallthrough]];
widget/windows/KeyboardLayout.cpp(1973,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
default:
^
widget/windows/KeyboardLayout.cpp(1973,5): note: insert 'U_FALLTHROUGH;' to silence this warning
default:
^
U_FALLTHROUGH;
widget/windows/WinMouseScrollHandler.cpp(633,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case SB_PAGEDOWN:
^
widget/windows/WinMouseScrollHandler.cpp(633,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case SB_PAGEDOWN:
^
U_FALLTHROUGH;
widget/windows/WinMouseScrollHandler.cpp(640,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case SB_LINEDOWN:
^
widget/windows/WinMouseScrollHandler.cpp(640,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case SB_LINEDOWN:
^
U_FALLTHROUGH;
widget/windows/nsLookAndFeel.cpp(188,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case ColorID::MozMenuhovertext:
^
widget/windows/nsLookAndFeel.cpp(188,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case ColorID::MozMenuhovertext:
^
U_FALLTHROUGH;
widget/windows/nsLookAndFeel.cpp(194,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case ColorID::Highlighttext:
^
widget/windows/nsLookAndFeel.cpp(194,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case ColorID::Highlighttext:
^
U_FALLTHROUGH;
widget/windows/nsLookAndFeel.cpp(469,15): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case ABE_BOTTOM:
^
widget/windows/nsLookAndFeel.cpp(469,15): note: insert 'U_FALLTHROUGH;' to silence this warning
case ABE_BOTTOM:
^
U_FALLTHROUGH;
widget/windows/nsNativeThemeWin.cpp(2540,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case StyleAppearance::Button:
^
widget/windows/nsNativeThemeWin.cpp(2540,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case StyleAppearance::Button:
^
U_FALLTHROUGH;
widget/windows/nsNativeThemeWin.cpp(3278,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case StyleAppearance::Checkbox:
^
widget/windows/nsNativeThemeWin.cpp(3278,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case StyleAppearance::Checkbox:
^
U_FALLTHROUGH;
widget/windows/nsNativeThemeWin.cpp(3332,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case StyleAppearance::Tabpanel:
^
widget/windows/nsNativeThemeWin.cpp(3332,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case StyleAppearance::Tabpanel:
^
U_FALLTHROUGH;
widget/windows/nsNativeThemeWin.cpp(3461,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case StyleAppearance::Menuarrow: {
^
widget/windows/nsNativeThemeWin.cpp(3461,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case StyleAppearance::Menuarrow: {
^
U_FALLTHROUGH;
widget/windows/nsWindow.cpp(1339,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case eWindowType_toplevel:
^
widget/windows/nsWindow.cpp(1339,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case eWindowType_toplevel:
^
U_FALLTHROUGH;
widget/windows/nsWindow.cpp(1422,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case eWindowType_toplevel:
^
widget/windows/nsWindow.cpp(1422,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case eWindowType_toplevel:
^
U_FALLTHROUGH;
widget/windows/nsWindow.cpp(3379,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case eTransparencyGlass:
^
widget/windows/nsWindow.cpp(3379,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case eTransparencyGlass:
^
U_FALLTHROUGH;
widget/windows/nsWindow.cpp(5595,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case WM_MOUSELEAVE: {
^
widget/windows/nsWindow.cpp(5595,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case WM_MOUSELEAVE: {
^
U_FALLTHROUGH;
xpcom/io/SpecialSystemDirectory.cpp(572,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case Win_Programs: {
^
xpcom/io/SpecialSystemDirectory.cpp(572,5): note: insert '[[fallthrough]];' to silence this warning
case Win_Programs: {
^
[[fallthrough]];
Differential Revision: https://phabricator.services.mozilla.com/D144668
It looks like it was added to abstract commonalities between Win32 and
WinRT. But we dropped support for WinRT a long time ago, and there hasn't been
any work on this area of code in 8 years. In the meantime, it just adds an
extra layer of indirection that doesn't need to exist.
Differential Revision: https://phabricator.services.mozilla.com/D139771
Currently, log names of IME handlers and keyboard event handlers are considered
from the class names. However, some of them are older name, and some of them
are for multiple classes. This is hard to remember when I tell bug reporters
to log the behavior in their environment. Therefore, I'd like to name all
IME handlers' log module name is `IMEHandler`, and all keyboard handlers'
log module name is `KeyboardHandler`.
Without dumping each key mapping on Windows, the log level `4` (`LogLevel::Debug`)
is enough. `KeyboardHandler:5` is really noisy on Windows. So, new logging
preparation becomes:
`MOZ_LOG=IMEHandler:4,sync`
`MOZ_LOG=KeyboardHandler:4,sync`
or
`MOZ_LOG=IMEHandler:4,KeyboardHandler:4,sync`
Differential Revision: https://phabricator.services.mozilla.com/D133183
This is the second of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D107150
This is the second of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D107150
Before deleting `IMEState::Enabled::PLUGIN`, let's make it an enum class
for making the change safer. Almost all of this change is done by
"replace" of VSCode.
Differential Revision: https://phabricator.services.mozilla.com/D100100
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
There's no use case for stateful comparators, so they can be just plain
function pointers.
This is used in some hot places like CSS selector matching.
Differential Revision: https://phabricator.services.mozilla.com/D77084
Masayuki Nakano