2013-09-24 10:04:16 +00:00
|
|
|
/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
|
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
|
|
|
|
2022-02-15 08:00:05 +00:00
|
|
|
#include "BasicEvents.h"
|
|
|
|
#include "ContentEvents.h"
|
|
|
|
#include "MiscEvents.h"
|
|
|
|
#include "MouseEvents.h"
|
|
|
|
#include "NativeKeyBindingsType.h"
|
|
|
|
#include "TextEventDispatcher.h"
|
|
|
|
#include "TextEvents.h"
|
|
|
|
#include "TouchEvents.h"
|
|
|
|
|
Bug 1905267 - part 2: Make `PresShell` not use non-element event target when target frame is destroyed and the event wants `Element` target r=smaug
When event target frame is destroyed, `PresShell::NotifyDestroyingFrame` updates
current event target content to the frame content. However, event target of
some DOM events need to be `Element`. Therefore,
`PresShell::mCurrentEventTarget` needs to store at least the handling
`EventMessage` to consider whether the event target can be non-element content
node or only element node. So, we need to make `PresShell::EventTargetInfo`
store `EventMessage`. Then, we can make `PresShell::NotifyDestroyingFrame`
prefer inclusive ancestor element as new event target from the `EventMessage`.
Although I don't understand what's going on the reported case, but I found the
simple case when event target is changed to a `Text` with the assertion in
`PresShell::DispatchEventToDOM`. Therefore, this patch has a new test.
Note that if target frame is a frame for element, e.g., when event target is
a focused element, `IsForbiddenDispatchingToNonElementContent` result won't
change the behavior. Therefore, its implementation is not optimized for
non-user input events.
Differential Revision: https://phabricator.services.mozilla.com/D217205
2024-07-30 00:06:10 +00:00
|
|
|
#include "mozilla/EventForwards.h"
|
2017-07-19 09:39:34 +00:00
|
|
|
#include "mozilla/EventStateManager.h"
|
2014-02-27 10:51:15 +00:00
|
|
|
#include "mozilla/InternalMutationEvent.h"
|
Bug 1685491 - part 5: Move the code remapping arrow keys in vertical content to `NativeKeyBindings` r=smaug,jfkthame
Currently, this feature is implemented only on Linux and macOS (see also
bug 1077515 and bug 1301497), and the code is really similar each other.
Additionally, it always tries to query selection to check whether the caret is
in vertical content or not if arrow keys are pressed. For avoiding a lot of
query, this patch makes `TextEventDispatcher` cache writing mode at every
selection change notification. However, unfortunately, it's not available when
non-editable content has focus, but it should be out of scope of this bug since
it requires a lot of changes.
Anyway, with this patch, we can write a mochitest only on Linux and macOS.
The following patch adds a test for this as a fix of bug 1103374.
Differential Revision: https://phabricator.services.mozilla.com/D102881
2021-02-02 03:29:31 +00:00
|
|
|
#include "mozilla/Maybe.h"
|
2014-05-22 04:06:05 +00:00
|
|
|
#include "mozilla/Preferences.h"
|
Bug 1675847 - part 3: Make `ePointerClick` event dispatchers and handlers use `WidgetPointerEvent` r=smaug,search-reviewers,devtools-reviewers,nchevobbe,jteow
This patch makes the all `ePointerClick` event dispatcher in C++ code use
`WidgetPointerEvent` instead of `WidgetMouseEvent`.
Then, this patch also makes the all `click` event dispatcher in chrome code use
`PointerEvent` instead of `MouseEvent`. For detecting wrong trusted event
dispatching of `click` event, this patch adds assertion into `MouseEvent`.
Therefore, all chrome test dispatchers also changed to use `PointerEvent`.
Finally, this patch includes a change of a WPT. That checks the `pointerId`
caused by executing an access key. In this case, the value should be `-1`
rather than the default value `0` because Pointer Event spec defines so for
synthetic pointer events caused by non-pointing devices [1]. Chrome also
sets it to `-1` and fails [2]. Therefore, the new assertion will pass on both
Firefox and Chrome.
1. https://w3c.github.io/pointerevents/#dom-pointerevent-pointerid
2. https://wpt.fyi/results/uievents/interface/keyboard-accesskey-click-event.html?run_id=5087897523060736&run_id=5136270464647168&run_id=5163620816388096&run_id=5201281304231936
Differential Revision: https://phabricator.services.mozilla.com/D213001
2024-06-14 00:18:47 +00:00
|
|
|
#include "mozilla/StaticPrefs_dom.h"
|
2019-07-26 01:10:23 +00:00
|
|
|
#include "mozilla/StaticPrefs_mousewheel.h"
|
2019-08-26 20:25:42 +00:00
|
|
|
#include "mozilla/StaticPrefs_ui.h"
|
Bug 1685491 - part 5: Move the code remapping arrow keys in vertical content to `NativeKeyBindings` r=smaug,jfkthame
Currently, this feature is implemented only on Linux and macOS (see also
bug 1077515 and bug 1301497), and the code is really similar each other.
Additionally, it always tries to query selection to check whether the caret is
in vertical content or not if arrow keys are pressed. For avoiding a lot of
query, this patch makes `TextEventDispatcher` cache writing mode at every
selection change notification. However, unfortunately, it's not available when
non-editable content has focus, but it should be out of scope of this bug since
it requires a lot of changes.
Anyway, with this patch, we can write a mochitest only on Linux and macOS.
The following patch adds a test for this as a fix of bug 1103374.
Differential Revision: https://phabricator.services.mozilla.com/D102881
2021-02-02 03:29:31 +00:00
|
|
|
#include "mozilla/WritingModes.h"
|
2018-02-09 16:17:09 +00:00
|
|
|
#include "mozilla/dom/KeyboardEventBinding.h"
|
Bug 1844723 - Make `CreateMouseOrPointerWidgetEvent()` set `mButton` to "not pressed" value and compute `mButtons` if the source event has not been dispatched yet r=edgar,dom-core
`CreateMouseOrPointerWidgetEvent()` is designed to create `mouseenter`,
`mouseover`, `mouseout`, `mouseleave`, `pointerenter`, `pointerover`,
`pointerout` and `pointerleave` from a source event.
They are not button state change events, but the source event may be so.
According to the WPTs ([1], [2]) and the fact that the other browsers pass the
tests, the button state of pointer events of synthesizing events should be
synchronized with what the web apps notified (i.e., previous state of the
source event) if and only if the input source supports hover state and the
source event which changes a button state has not been dispatched into the DOM
yet.
1. https://searchfox.org/mozilla-central/rev/08d53deb2cf587e68d1825082c955e8a1926be73/testing/web-platform/tests/pointerevents/pointerevent_attributes_hoverable_pointers.html#44,51,60,63
2. https://searchfox.org/mozilla-central/rev/08d53deb2cf587e68d1825082c955e8a1926be73/testing/web-platform/tests/pointerevents/pointerevent_attributes_nohover_pointers.html#17,45,47,51
Differential Revision: https://phabricator.services.mozilla.com/D187644
2023-10-10 07:33:05 +00:00
|
|
|
#include "mozilla/dom/MouseEventBinding.h"
|
2021-05-14 17:44:29 +00:00
|
|
|
#include "mozilla/dom/WheelEventBinding.h"
|
2019-05-21 07:47:51 +00:00
|
|
|
#include "nsCommandParams.h"
|
2017-07-10 08:42:01 +00:00
|
|
|
#include "nsContentUtils.h"
|
2017-07-19 09:39:34 +00:00
|
|
|
#include "nsIContent.h"
|
2019-12-21 12:27:06 +00:00
|
|
|
#include "nsIDragSession.h"
|
Bug 1297013 part.2 Implement some helper methods to log constants related to event handling r=smaug
This patch implements some helper methods to log constants related to event handling.
ToString(KeyNameIndex) and ToString(CodeNameIndex) converts the enum itmes to human readable string. They use WidgetKeyboardEvent's helper class which returns Unicode text. Therefore, this need to convert from UTF16 to UTF8. That's the reason why these methods don't return |const char*|.
GetDOMKeyCodeName(uint32_t) returns DOM keycode name if it's defined. Otherwise, returns hexadecimal value. For generating switch-case statement, VirtualKeyCodeList.h shouldn't include ",". Therefore, this patch removes "," from VirtualKeyCodeList.h and append it at defining NS_DEFINE_VK. Additionally, the last item of enum and array should not end with ",". Therefore, this adds dummy last item at each of them. Finally, some of the keyCode values are shared between 2 keys. Therefore, it needs to support NS_DISALLOW_SAME_KEYCODE for switch-case generator. See the comment in the file for more detail.
GetModifiersName(Modifiers) returns all modifier names included in the given value.
MozReview-Commit-ID: 9i2ftFOTpDn
--HG--
extra : rebase_source : 458a4d28624dc10dd4454f2e7708d746d1fcb045
2016-09-14 15:48:47 +00:00
|
|
|
#include "nsPrintfCString.h"
|
2013-09-24 10:04:16 +00:00
|
|
|
|
2019-10-16 21:24:48 +00:00
|
|
|
#if defined(XP_WIN)
|
2023-04-01 08:31:12 +00:00
|
|
|
# include "windef.h"
|
|
|
|
# include "winnetwk.h"
|
2019-10-16 21:24:48 +00:00
|
|
|
# include "npapi.h"
|
2020-10-27 15:16:49 +00:00
|
|
|
# include "WinUtils.h"
|
Bug 1685491 - part.1: Map typical commands to synthesized keyboard events for test on Linux and macOS r=smaug,remote-protocol-reviewers
Currently, we don't allow keyboard events synthesized for tests retrieve native
key bindings in content process. However, due to this, we cannot test keyboard
navigation, deleting per word, etc on Linux and macOS either with mochitest
or WPT. For making better compatibility with the other browsers, we should
write WPT more with the test driver. Therefore, we should allow keyboard
events synthesized for tests retrieve native key bindings.
On the other hand, if we make them retrieve customized keyboard shortcuts
in the environment, some developers may not be able to run tests locally without
resetting their customization. Therefore, this patch makes `NativeKeyBindings`
set "standard" shortcut keys on the platform instead of retrieving actual
shortcut key results.
If referring the default shortcut key bindings is not good thing for
WebDriver/CDP, perhaps, `TextInputProcessor` should have a new flag which can
refer customized shortcut keys even in content process. But I think that it
should be done in another bug because some edit commands are mapped forcibly
like this patch.
https://searchfox.org/mozilla-central/rev/c03e8de87cdb0ce0378c0886d3c0ce8bbf9dc44e/remote/domains/parent/Input.jsm#82-102
Differential Revision: https://phabricator.services.mozilla.com/D102877
2021-02-02 03:02:30 +00:00
|
|
|
#endif // #if defined (XP_WIN)
|
|
|
|
|
|
|
|
#if defined(MOZ_WIDGET_GTK) || defined(XP_MACOSX)
|
|
|
|
# include "NativeKeyBindings.h"
|
|
|
|
#endif // #if defined(MOZ_WIDGET_GTK) || defined(XP_MACOSX)
|
2019-10-16 21:24:48 +00:00
|
|
|
|
2013-09-24 10:04:16 +00:00
|
|
|
namespace mozilla {
|
|
|
|
|
2015-09-17 03:05:44 +00:00
|
|
|
/******************************************************************************
|
|
|
|
* Global helper methods
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
const char* ToChar(EventMessage aEventMessage) {
|
|
|
|
switch (aEventMessage) {
|
|
|
|
#define NS_EVENT_MESSAGE(aMessage) \
|
|
|
|
case aMessage: \
|
|
|
|
return #aMessage;
|
|
|
|
|
|
|
|
#include "mozilla/EventMessageList.h"
|
|
|
|
|
|
|
|
#undef NS_EVENT_MESSAGE
|
|
|
|
default:
|
|
|
|
return "illegal event message";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Bug 1675847 - part 3: Make `ePointerClick` event dispatchers and handlers use `WidgetPointerEvent` r=smaug,search-reviewers,devtools-reviewers,nchevobbe,jteow
This patch makes the all `ePointerClick` event dispatcher in C++ code use
`WidgetPointerEvent` instead of `WidgetMouseEvent`.
Then, this patch also makes the all `click` event dispatcher in chrome code use
`PointerEvent` instead of `MouseEvent`. For detecting wrong trusted event
dispatching of `click` event, this patch adds assertion into `MouseEvent`.
Therefore, all chrome test dispatchers also changed to use `PointerEvent`.
Finally, this patch includes a change of a WPT. That checks the `pointerId`
caused by executing an access key. In this case, the value should be `-1`
rather than the default value `0` because Pointer Event spec defines so for
synthetic pointer events caused by non-pointing devices [1]. Chrome also
sets it to `-1` and fails [2]. Therefore, the new assertion will pass on both
Firefox and Chrome.
1. https://w3c.github.io/pointerevents/#dom-pointerevent-pointerid
2. https://wpt.fyi/results/uievents/interface/keyboard-accesskey-click-event.html?run_id=5087897523060736&run_id=5136270464647168&run_id=5163620816388096&run_id=5201281304231936
Differential Revision: https://phabricator.services.mozilla.com/D213001
2024-06-14 00:18:47 +00:00
|
|
|
bool IsPointerEventMessage(EventMessage aMessage) {
|
|
|
|
switch (aMessage) {
|
|
|
|
case ePointerDown:
|
|
|
|
case ePointerMove:
|
|
|
|
case ePointerUp:
|
|
|
|
case ePointerCancel:
|
|
|
|
case ePointerOver:
|
|
|
|
case ePointerOut:
|
|
|
|
case ePointerEnter:
|
|
|
|
case ePointerLeave:
|
|
|
|
case ePointerGotCapture:
|
|
|
|
case ePointerLostCapture:
|
|
|
|
case ePointerClick:
|
2024-06-14 00:18:47 +00:00
|
|
|
case ePointerAuxClick:
|
2024-06-14 00:18:48 +00:00
|
|
|
case eContextMenu:
|
Bug 1904279 - Get rid of `dom.w3c_pointer_events.dispatch_click_as_pointer_event` pref r=smaug,pip-reviewers,search-reviewers,devtools-reviewers,urlbar-reviewers,nchevobbe,dao,jteow,mconley
Keep supporting the pref makes a lot of `click`, `auxclick` and `contextmenu`
event creators complicated (and look messy). So, let's delete it as soon as
possible.
Differential Revision: https://phabricator.services.mozilla.com/D217225
2024-07-30 06:49:42 +00:00
|
|
|
return true;
|
Bug 1675847 - part 3: Make `ePointerClick` event dispatchers and handlers use `WidgetPointerEvent` r=smaug,search-reviewers,devtools-reviewers,nchevobbe,jteow
This patch makes the all `ePointerClick` event dispatcher in C++ code use
`WidgetPointerEvent` instead of `WidgetMouseEvent`.
Then, this patch also makes the all `click` event dispatcher in chrome code use
`PointerEvent` instead of `MouseEvent`. For detecting wrong trusted event
dispatching of `click` event, this patch adds assertion into `MouseEvent`.
Therefore, all chrome test dispatchers also changed to use `PointerEvent`.
Finally, this patch includes a change of a WPT. That checks the `pointerId`
caused by executing an access key. In this case, the value should be `-1`
rather than the default value `0` because Pointer Event spec defines so for
synthetic pointer events caused by non-pointing devices [1]. Chrome also
sets it to `-1` and fails [2]. Therefore, the new assertion will pass on both
Firefox and Chrome.
1. https://w3c.github.io/pointerevents/#dom-pointerevent-pointerid
2. https://wpt.fyi/results/uievents/interface/keyboard-accesskey-click-event.html?run_id=5087897523060736&run_id=5136270464647168&run_id=5163620816388096&run_id=5201281304231936
Differential Revision: https://phabricator.services.mozilla.com/D213001
2024-06-14 00:18:47 +00:00
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
bool IsPointerEventMessageOriginallyMouseEventMessage(EventMessage aMessage) {
|
Bug 1904279 - Get rid of `dom.w3c_pointer_events.dispatch_click_as_pointer_event` pref r=smaug,pip-reviewers,search-reviewers,devtools-reviewers,urlbar-reviewers,nchevobbe,dao,jteow,mconley
Keep supporting the pref makes a lot of `click`, `auxclick` and `contextmenu`
event creators complicated (and look messy). So, let's delete it as soon as
possible.
Differential Revision: https://phabricator.services.mozilla.com/D217225
2024-07-30 06:49:42 +00:00
|
|
|
return aMessage == ePointerClick || aMessage == ePointerAuxClick ||
|
|
|
|
aMessage == eContextMenu;
|
Bug 1675847 - part 3: Make `ePointerClick` event dispatchers and handlers use `WidgetPointerEvent` r=smaug,search-reviewers,devtools-reviewers,nchevobbe,jteow
This patch makes the all `ePointerClick` event dispatcher in C++ code use
`WidgetPointerEvent` instead of `WidgetMouseEvent`.
Then, this patch also makes the all `click` event dispatcher in chrome code use
`PointerEvent` instead of `MouseEvent`. For detecting wrong trusted event
dispatching of `click` event, this patch adds assertion into `MouseEvent`.
Therefore, all chrome test dispatchers also changed to use `PointerEvent`.
Finally, this patch includes a change of a WPT. That checks the `pointerId`
caused by executing an access key. In this case, the value should be `-1`
rather than the default value `0` because Pointer Event spec defines so for
synthetic pointer events caused by non-pointing devices [1]. Chrome also
sets it to `-1` and fails [2]. Therefore, the new assertion will pass on both
Firefox and Chrome.
1. https://w3c.github.io/pointerevents/#dom-pointerevent-pointerid
2. https://wpt.fyi/results/uievents/interface/keyboard-accesskey-click-event.html?run_id=5087897523060736&run_id=5136270464647168&run_id=5163620816388096&run_id=5201281304231936
Differential Revision: https://phabricator.services.mozilla.com/D213001
2024-06-14 00:18:47 +00:00
|
|
|
}
|
|
|
|
|
Bug 1905267 - part 2: Make `PresShell` not use non-element event target when target frame is destroyed and the event wants `Element` target r=smaug
When event target frame is destroyed, `PresShell::NotifyDestroyingFrame` updates
current event target content to the frame content. However, event target of
some DOM events need to be `Element`. Therefore,
`PresShell::mCurrentEventTarget` needs to store at least the handling
`EventMessage` to consider whether the event target can be non-element content
node or only element node. So, we need to make `PresShell::EventTargetInfo`
store `EventMessage`. Then, we can make `PresShell::NotifyDestroyingFrame`
prefer inclusive ancestor element as new event target from the `EventMessage`.
Although I don't understand what's going on the reported case, but I found the
simple case when event target is changed to a `Text` with the assertion in
`PresShell::DispatchEventToDOM`. Therefore, this patch has a new test.
Note that if target frame is a frame for element, e.g., when event target is
a focused element, `IsForbiddenDispatchingToNonElementContent` result won't
change the behavior. Therefore, its implementation is not optimized for
non-user input events.
Differential Revision: https://phabricator.services.mozilla.com/D217205
2024-07-30 00:06:10 +00:00
|
|
|
bool IsForbiddenDispatchingToNonElementContent(EventMessage aMessage) {
|
|
|
|
switch (aMessage) {
|
|
|
|
// Keyboard event target should be an Element node
|
|
|
|
case eKeyDown:
|
|
|
|
case eKeyUp:
|
|
|
|
case eKeyPress:
|
|
|
|
// Mouse event target should be an Element node
|
|
|
|
case eMouseMove:
|
|
|
|
case eMouseUp:
|
|
|
|
case eMouseDown:
|
|
|
|
case eMouseEnterIntoWidget:
|
|
|
|
case eMouseExitFromWidget:
|
|
|
|
case eMouseDoubleClick:
|
|
|
|
case eMouseActivate:
|
|
|
|
case eMouseOver:
|
|
|
|
case eMouseOut:
|
|
|
|
case eMouseHitTest:
|
|
|
|
case eMouseEnter:
|
|
|
|
case eMouseLeave:
|
|
|
|
case eMouseTouchDrag:
|
|
|
|
case eMouseLongTap:
|
|
|
|
case eMouseExploreByTouch:
|
|
|
|
// Pointer event target should be an Element node
|
|
|
|
case ePointerClick:
|
|
|
|
case ePointerAuxClick:
|
|
|
|
case ePointerMove:
|
|
|
|
case ePointerUp:
|
|
|
|
case ePointerDown:
|
|
|
|
case ePointerOver:
|
|
|
|
case ePointerOut:
|
|
|
|
case ePointerEnter:
|
|
|
|
case ePointerLeave:
|
|
|
|
case ePointerCancel:
|
|
|
|
case ePointerGotCapture:
|
|
|
|
case ePointerLostCapture:
|
|
|
|
case eContextMenu:
|
|
|
|
// Drag event target should be an Element node
|
|
|
|
case eDragEnter:
|
|
|
|
case eDragOver:
|
|
|
|
case eDragExit:
|
|
|
|
case eDrag:
|
|
|
|
case eDragEnd:
|
|
|
|
case eDragStart:
|
|
|
|
case eDrop:
|
|
|
|
case eDragLeave:
|
2024-09-11 23:02:22 +00:00
|
|
|
case eQueryDropTargetHittest:
|
Bug 1905267 - part 2: Make `PresShell` not use non-element event target when target frame is destroyed and the event wants `Element` target r=smaug
When event target frame is destroyed, `PresShell::NotifyDestroyingFrame` updates
current event target content to the frame content. However, event target of
some DOM events need to be `Element`. Therefore,
`PresShell::mCurrentEventTarget` needs to store at least the handling
`EventMessage` to consider whether the event target can be non-element content
node or only element node. So, we need to make `PresShell::EventTargetInfo`
store `EventMessage`. Then, we can make `PresShell::NotifyDestroyingFrame`
prefer inclusive ancestor element as new event target from the `EventMessage`.
Although I don't understand what's going on the reported case, but I found the
simple case when event target is changed to a `Text` with the assertion in
`PresShell::DispatchEventToDOM`. Therefore, this patch has a new test.
Note that if target frame is a frame for element, e.g., when event target is
a focused element, `IsForbiddenDispatchingToNonElementContent` result won't
change the behavior. Therefore, its implementation is not optimized for
non-user input events.
Differential Revision: https://phabricator.services.mozilla.com/D217205
2024-07-30 00:06:10 +00:00
|
|
|
// case mouse wheel related message target should be an Element node
|
|
|
|
case eLegacyMouseLineOrPageScroll:
|
|
|
|
case eLegacyMousePixelScroll:
|
|
|
|
case eWheel:
|
|
|
|
// Composition event message target should be an Element node
|
|
|
|
case eCompositionStart:
|
|
|
|
case eCompositionEnd:
|
|
|
|
case eCompositionUpdate:
|
|
|
|
case eCompositionChange:
|
|
|
|
case eCompositionCommitAsIs:
|
|
|
|
case eCompositionCommit:
|
|
|
|
case eCompositionCommitRequestHandled:
|
|
|
|
// Gesture event target should be an Element node
|
|
|
|
case eSwipeGestureMayStart:
|
|
|
|
case eSwipeGestureStart:
|
|
|
|
case eSwipeGestureUpdate:
|
|
|
|
case eSwipeGestureEnd:
|
|
|
|
case eSwipeGesture:
|
|
|
|
case eMagnifyGestureStart:
|
|
|
|
case eMagnifyGestureUpdate:
|
|
|
|
case eMagnifyGesture:
|
|
|
|
case eRotateGestureStart:
|
|
|
|
case eRotateGestureUpdate:
|
|
|
|
case eRotateGesture:
|
|
|
|
case eTapGesture:
|
|
|
|
case ePressTapGesture:
|
|
|
|
case eEdgeUIStarted:
|
|
|
|
case eEdgeUICanceled:
|
|
|
|
case eEdgeUICompleted:
|
|
|
|
// Touch event target should be an Element node
|
|
|
|
case eTouchStart:
|
|
|
|
case eTouchMove:
|
|
|
|
case eTouchEnd:
|
|
|
|
case eTouchCancel:
|
|
|
|
case eTouchPointerCancel:
|
|
|
|
return true;
|
|
|
|
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-09-17 03:05:44 +00:00
|
|
|
const char* ToChar(EventClassID aEventClassID) {
|
|
|
|
switch (aEventClassID) {
|
|
|
|
#define NS_ROOT_EVENT_CLASS(aPrefix, aName) \
|
|
|
|
case eBasic##aName##Class: \
|
|
|
|
return "eBasic" #aName "Class";
|
|
|
|
|
|
|
|
#define NS_EVENT_CLASS(aPrefix, aName) \
|
|
|
|
case e##aName##Class: \
|
|
|
|
return "e" #aName "Class";
|
|
|
|
|
|
|
|
#include "mozilla/EventClassList.h"
|
|
|
|
|
|
|
|
#undef NS_EVENT_CLASS
|
|
|
|
#undef NS_ROOT_EVENT_CLASS
|
|
|
|
default:
|
|
|
|
return "illegal event class ID";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Bug 1297013 part.2 Implement some helper methods to log constants related to event handling r=smaug
This patch implements some helper methods to log constants related to event handling.
ToString(KeyNameIndex) and ToString(CodeNameIndex) converts the enum itmes to human readable string. They use WidgetKeyboardEvent's helper class which returns Unicode text. Therefore, this need to convert from UTF16 to UTF8. That's the reason why these methods don't return |const char*|.
GetDOMKeyCodeName(uint32_t) returns DOM keycode name if it's defined. Otherwise, returns hexadecimal value. For generating switch-case statement, VirtualKeyCodeList.h shouldn't include ",". Therefore, this patch removes "," from VirtualKeyCodeList.h and append it at defining NS_DEFINE_VK. Additionally, the last item of enum and array should not end with ",". Therefore, this adds dummy last item at each of them. Finally, some of the keyCode values are shared between 2 keys. Therefore, it needs to support NS_DISALLOW_SAME_KEYCODE for switch-case generator. See the comment in the file for more detail.
GetModifiersName(Modifiers) returns all modifier names included in the given value.
MozReview-Commit-ID: 9i2ftFOTpDn
--HG--
extra : rebase_source : 458a4d28624dc10dd4454f2e7708d746d1fcb045
2016-09-14 15:48:47 +00:00
|
|
|
const nsCString ToString(KeyNameIndex aKeyNameIndex) {
|
|
|
|
if (aKeyNameIndex == KEY_NAME_INDEX_USE_STRING) {
|
|
|
|
return "USE_STRING"_ns;
|
|
|
|
}
|
|
|
|
nsAutoString keyName;
|
|
|
|
WidgetKeyboardEvent::GetDOMKeyName(aKeyNameIndex, keyName);
|
|
|
|
return NS_ConvertUTF16toUTF8(keyName);
|
|
|
|
}
|
|
|
|
|
|
|
|
const nsCString ToString(CodeNameIndex aCodeNameIndex) {
|
|
|
|
if (aCodeNameIndex == CODE_NAME_INDEX_USE_STRING) {
|
|
|
|
return "USE_STRING"_ns;
|
|
|
|
}
|
|
|
|
nsAutoString codeName;
|
|
|
|
WidgetKeyboardEvent::GetDOMCodeName(aCodeNameIndex, codeName);
|
|
|
|
return NS_ConvertUTF16toUTF8(codeName);
|
|
|
|
}
|
|
|
|
|
2017-12-02 01:46:31 +00:00
|
|
|
const char* ToChar(Command aCommand) {
|
2019-04-30 04:23:24 +00:00
|
|
|
if (aCommand == Command::DoNothing) {
|
2017-12-02 01:46:31 +00:00
|
|
|
return "CommandDoNothing";
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (aCommand) {
|
|
|
|
#define NS_DEFINE_COMMAND(aName, aCommandStr) \
|
2019-04-30 04:23:24 +00:00
|
|
|
case Command::aName: \
|
|
|
|
return "Command::" #aName;
|
Bug 1546839 - part 2: Define commands which are handled by editor r=smaug
`NS_DEFINE_COMMAND_WITH_PARAM` macro is special case for `cmd_align`.
`cmd_align` can be mapped to multiple `Command` values. It's distinguished
with additional parameter, '"left"', '"right"', '"center"' or '"justify"'.
Therefore, we cannot map from XUL command to `Command` value simply with
hashtable created by the next patch. So, this new macro is necessary for
the next patch to ignore this special case.
The used commands are listed up from:
* [converted from `execCommand`, `cmd_bold` - `cmd_superscript`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2066-2071)
* [converted from `execCommand`, `cmd_undo` - `cmd_redo`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2078-2079)
* [converted from `execCommand`, `cmd_paragraphState` - `cmd_outdent`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2080-2081,2105-2106)
* [converted from `execCommand`, `cmd_align`s](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2095-2098)
* [converted from `execCommand`, `cmd_highlight` - `cmd_decreaseFont`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2082-2088)
* [converted from `execCommand`, `cmd_insertHR` - `cmd_ul`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2089-2093,2101-2102)
* [converted from `execCommand`, `cmd_getContents` - `cmd_enableAbsolutePositionEditing`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2094,2099-2100,2107-2113)
* [internal commands, `obs_documentCreated` - `obs_documentWillBeDestroyed`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#26-28)
* [internal command, `cmd_abbr`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#68)
* [internal command, `cmd_absPos`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#102)
* [internal commands, `cmd_acronym` - `cmd_var`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#58,63,65-67,69-72)
* [internal commands, `cmd_dd` - `cmd_dt`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#78-79)
* [internal commands, `cmd_moveDown` - `cmd_selectUp2`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/EditorController.cpp#97-112)
* [internal command, `cmd_setDocumentModified`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#31)
Differential Revision: https://phabricator.services.mozilla.com/D29171
--HG--
extra : moz-landing-system : lando
2019-04-30 06:04:01 +00:00
|
|
|
#define NS_DEFINE_COMMAND_WITH_PARAM(aName, aCommandStr, aParam) \
|
|
|
|
case Command::aName: \
|
|
|
|
return "Command::" #aName;
|
Bug 1403759 - part 2: Handle edit/selection commands like insertNewline: in TextInputHandler::HandleCommand() r=m_kato
Let's make TextInputHandler::HandleCommand() handle other
commands which are caused by Backspace, Delete, Tab, ArrowUp,
ArrowDown, ArrowRight, ArrowLeft, PageUp, PageDown, Home, End
and Escape keys with various modifiers.
This patch makes Korean users can do most key operation in
editor even with composing Hangul character.
Note that this patch has a hack for cancelOperation: command.
The command is typically fired for Escape key press. However,
it's also fired for Command + Period. Unfortunately, this
behavior is really odd if subclass of NSResponder implements
|void cancelOperation:(id)sender|. If it's implemented,
Cocoa doesn't call its |void keyDown:(NSEvent)theEvent|.
Instead, it calls only |void doCommandBySelector:(SEL)aSelector|
and |void cancelOperation:(id)sender| when Command + Period is
pressed. Therefore, we cannot dispatch keydown nor keypress
event for this key combination if we implement it. Therefore,
this patch doesn't implement the method but handle it in
doCommandBySelector even though the super class of ChildView
cannot handle the command with this path.
MozReview-Commit-ID: 4hS23SiwNJv
--HG--
extra : rebase_source : 38ac1ea494b5f786ecd5c9327efbacd460b59faf
2017-12-02 05:53:10 +00:00
|
|
|
#define NS_DEFINE_COMMAND_NO_EXEC_COMMAND(aName) \
|
2019-04-30 04:23:24 +00:00
|
|
|
case Command::aName: \
|
|
|
|
return "Command::" #aName;
|
2017-12-02 01:46:31 +00:00
|
|
|
|
|
|
|
#include "mozilla/CommandList.h"
|
|
|
|
|
|
|
|
#undef NS_DEFINE_COMMAND
|
Bug 1546839 - part 2: Define commands which are handled by editor r=smaug
`NS_DEFINE_COMMAND_WITH_PARAM` macro is special case for `cmd_align`.
`cmd_align` can be mapped to multiple `Command` values. It's distinguished
with additional parameter, '"left"', '"right"', '"center"' or '"justify"'.
Therefore, we cannot map from XUL command to `Command` value simply with
hashtable created by the next patch. So, this new macro is necessary for
the next patch to ignore this special case.
The used commands are listed up from:
* [converted from `execCommand`, `cmd_bold` - `cmd_superscript`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2066-2071)
* [converted from `execCommand`, `cmd_undo` - `cmd_redo`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2078-2079)
* [converted from `execCommand`, `cmd_paragraphState` - `cmd_outdent`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2080-2081,2105-2106)
* [converted from `execCommand`, `cmd_align`s](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2095-2098)
* [converted from `execCommand`, `cmd_highlight` - `cmd_decreaseFont`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2082-2088)
* [converted from `execCommand`, `cmd_insertHR` - `cmd_ul`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2089-2093,2101-2102)
* [converted from `execCommand`, `cmd_getContents` - `cmd_enableAbsolutePositionEditing`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2094,2099-2100,2107-2113)
* [internal commands, `obs_documentCreated` - `obs_documentWillBeDestroyed`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#26-28)
* [internal command, `cmd_abbr`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#68)
* [internal command, `cmd_absPos`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#102)
* [internal commands, `cmd_acronym` - `cmd_var`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#58,63,65-67,69-72)
* [internal commands, `cmd_dd` - `cmd_dt`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#78-79)
* [internal commands, `cmd_moveDown` - `cmd_selectUp2`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/EditorController.cpp#97-112)
* [internal command, `cmd_setDocumentModified`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#31)
Differential Revision: https://phabricator.services.mozilla.com/D29171
--HG--
extra : moz-landing-system : lando
2019-04-30 06:04:01 +00:00
|
|
|
#undef NS_DEFINE_COMMAND_WITH_PARAM
|
Bug 1403759 - part 2: Handle edit/selection commands like insertNewline: in TextInputHandler::HandleCommand() r=m_kato
Let's make TextInputHandler::HandleCommand() handle other
commands which are caused by Backspace, Delete, Tab, ArrowUp,
ArrowDown, ArrowRight, ArrowLeft, PageUp, PageDown, Home, End
and Escape keys with various modifiers.
This patch makes Korean users can do most key operation in
editor even with composing Hangul character.
Note that this patch has a hack for cancelOperation: command.
The command is typically fired for Escape key press. However,
it's also fired for Command + Period. Unfortunately, this
behavior is really odd if subclass of NSResponder implements
|void cancelOperation:(id)sender|. If it's implemented,
Cocoa doesn't call its |void keyDown:(NSEvent)theEvent|.
Instead, it calls only |void doCommandBySelector:(SEL)aSelector|
and |void cancelOperation:(id)sender| when Command + Period is
pressed. Therefore, we cannot dispatch keydown nor keypress
event for this key combination if we implement it. Therefore,
this patch doesn't implement the method but handle it in
doCommandBySelector even though the super class of ChildView
cannot handle the command with this path.
MozReview-Commit-ID: 4hS23SiwNJv
--HG--
extra : rebase_source : 38ac1ea494b5f786ecd5c9327efbacd460b59faf
2017-12-02 05:53:10 +00:00
|
|
|
#undef NS_DEFINE_COMMAND_NO_EXEC_COMMAND
|
2017-12-02 01:46:31 +00:00
|
|
|
|
|
|
|
default:
|
|
|
|
return "illegal command value";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Bug 1297013 part.2 Implement some helper methods to log constants related to event handling r=smaug
This patch implements some helper methods to log constants related to event handling.
ToString(KeyNameIndex) and ToString(CodeNameIndex) converts the enum itmes to human readable string. They use WidgetKeyboardEvent's helper class which returns Unicode text. Therefore, this need to convert from UTF16 to UTF8. That's the reason why these methods don't return |const char*|.
GetDOMKeyCodeName(uint32_t) returns DOM keycode name if it's defined. Otherwise, returns hexadecimal value. For generating switch-case statement, VirtualKeyCodeList.h shouldn't include ",". Therefore, this patch removes "," from VirtualKeyCodeList.h and append it at defining NS_DEFINE_VK. Additionally, the last item of enum and array should not end with ",". Therefore, this adds dummy last item at each of them. Finally, some of the keyCode values are shared between 2 keys. Therefore, it needs to support NS_DISALLOW_SAME_KEYCODE for switch-case generator. See the comment in the file for more detail.
GetModifiersName(Modifiers) returns all modifier names included in the given value.
MozReview-Commit-ID: 9i2ftFOTpDn
--HG--
extra : rebase_source : 458a4d28624dc10dd4454f2e7708d746d1fcb045
2016-09-14 15:48:47 +00:00
|
|
|
const nsCString GetDOMKeyCodeName(uint32_t aKeyCode) {
|
|
|
|
switch (aKeyCode) {
|
|
|
|
#define NS_DISALLOW_SAME_KEYCODE
|
|
|
|
#define NS_DEFINE_VK(aDOMKeyName, aDOMKeyCode) \
|
|
|
|
case aDOMKeyCode: \
|
|
|
|
return nsLiteralCString(#aDOMKeyName);
|
|
|
|
|
|
|
|
#include "mozilla/VirtualKeyCodeList.h"
|
|
|
|
|
|
|
|
#undef NS_DEFINE_VK
|
|
|
|
#undef NS_DISALLOW_SAME_KEYCODE
|
|
|
|
|
|
|
|
default:
|
|
|
|
return nsPrintfCString("Invalid DOM keyCode (0x%08X)", aKeyCode);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-04-30 04:24:26 +00:00
|
|
|
/******************************************************************************
|
|
|
|
* non class method implementation
|
|
|
|
******************************************************************************/
|
|
|
|
|
2021-03-10 10:47:47 +00:00
|
|
|
static nsTHashMap<nsDepCharHashKey, Command>* sCommandHashtable = nullptr;
|
2019-04-30 04:24:26 +00:00
|
|
|
|
2019-05-21 07:47:51 +00:00
|
|
|
Command GetInternalCommand(const char* aCommandName,
|
|
|
|
const nsCommandParams* aCommandParams) {
|
2019-04-30 04:24:26 +00:00
|
|
|
if (!aCommandName) {
|
|
|
|
return Command::DoNothing;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Special cases for "cmd_align". It's mapped to multiple internal commands
|
|
|
|
// with additional param. Therefore, we cannot handle it with the hashtable.
|
|
|
|
if (!strcmp(aCommandName, "cmd_align")) {
|
2019-06-04 10:01:31 +00:00
|
|
|
if (!aCommandParams) {
|
|
|
|
// Note that if this is called by EditorCommand::IsCommandEnabled(),
|
|
|
|
// it cannot set aCommandParams. So, don't warn in this case even though
|
|
|
|
// this is illegal case for DoCommandParams().
|
|
|
|
return Command::FormatJustify;
|
2019-05-21 07:47:51 +00:00
|
|
|
}
|
|
|
|
nsAutoCString cValue;
|
|
|
|
nsresult rv = aCommandParams->GetCString("state_attribute", cValue);
|
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
nsString value; // Avoid copying the string buffer with using nsString.
|
|
|
|
rv = aCommandParams->GetString("state_attribute", value);
|
2019-06-04 10:01:31 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
return Command::FormatJustifyNone;
|
2019-05-21 07:47:51 +00:00
|
|
|
}
|
2020-09-02 09:54:37 +00:00
|
|
|
CopyUTF16toUTF8(value, cValue);
|
2019-05-21 07:47:51 +00:00
|
|
|
}
|
|
|
|
if (cValue.LowerCaseEqualsASCII("left")) {
|
2019-04-30 04:24:26 +00:00
|
|
|
return Command::FormatJustifyLeft;
|
|
|
|
}
|
2019-05-21 07:47:51 +00:00
|
|
|
if (cValue.LowerCaseEqualsASCII("right")) {
|
2019-04-30 04:24:26 +00:00
|
|
|
return Command::FormatJustifyRight;
|
|
|
|
}
|
2019-05-21 07:47:51 +00:00
|
|
|
if (cValue.LowerCaseEqualsASCII("center")) {
|
2019-04-30 04:24:26 +00:00
|
|
|
return Command::FormatJustifyCenter;
|
|
|
|
}
|
2019-05-21 07:47:51 +00:00
|
|
|
if (cValue.LowerCaseEqualsASCII("justify")) {
|
2019-04-30 04:24:26 +00:00
|
|
|
return Command::FormatJustifyFull;
|
|
|
|
}
|
2019-06-04 10:01:31 +00:00
|
|
|
if (cValue.IsEmpty()) {
|
|
|
|
return Command::FormatJustifyNone;
|
|
|
|
}
|
2019-04-30 04:24:26 +00:00
|
|
|
return Command::DoNothing;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!sCommandHashtable) {
|
2021-03-10 10:47:47 +00:00
|
|
|
sCommandHashtable = new nsTHashMap<nsDepCharHashKey, Command>();
|
2019-04-30 04:24:26 +00:00
|
|
|
#define NS_DEFINE_COMMAND(aName, aCommandStr) \
|
2021-02-26 09:11:46 +00:00
|
|
|
sCommandHashtable->InsertOrUpdate(#aCommandStr, Command::aName);
|
2019-04-30 04:24:26 +00:00
|
|
|
|
|
|
|
#define NS_DEFINE_COMMAND_WITH_PARAM(aName, aCommandStr, aParam)
|
|
|
|
|
|
|
|
#define NS_DEFINE_COMMAND_NO_EXEC_COMMAND(aName)
|
|
|
|
|
|
|
|
#include "mozilla/CommandList.h"
|
|
|
|
|
|
|
|
#undef NS_DEFINE_COMMAND
|
|
|
|
#undef NS_DEFINE_COMMAND_WITH_PARAM
|
|
|
|
#undef NS_DEFINE_COMMAND_NO_EXEC_COMMAND
|
|
|
|
}
|
|
|
|
Command command = Command::DoNothing;
|
|
|
|
if (!sCommandHashtable->Get(aCommandName, &command)) {
|
|
|
|
return Command::DoNothing;
|
|
|
|
}
|
|
|
|
return command;
|
|
|
|
}
|
|
|
|
|
2013-10-18 06:10:20 +00:00
|
|
|
/******************************************************************************
|
|
|
|
* As*Event() implementation
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
#define NS_ROOT_EVENT_CLASS(aPrefix, aName)
|
|
|
|
#define NS_EVENT_CLASS(aPrefix, aName) \
|
|
|
|
aPrefix##aName* WidgetEvent::As##aName() { return nullptr; } \
|
|
|
|
\
|
|
|
|
const aPrefix##aName* WidgetEvent::As##aName() const { \
|
|
|
|
return const_cast<WidgetEvent*>(this)->As##aName(); \
|
|
|
|
}
|
|
|
|
|
|
|
|
#include "mozilla/EventClassList.h"
|
|
|
|
|
|
|
|
#undef NS_EVENT_CLASS
|
|
|
|
#undef NS_ROOT_EVENT_CLASS
|
|
|
|
|
2013-09-24 10:04:16 +00:00
|
|
|
/******************************************************************************
|
|
|
|
* mozilla::WidgetEvent
|
|
|
|
*
|
|
|
|
* Event struct type checking methods.
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
bool WidgetEvent::IsQueryContentEvent() const {
|
2014-08-04 05:28:49 +00:00
|
|
|
return mClass == eQueryContentEventClass;
|
2013-09-24 10:04:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bool WidgetEvent::IsSelectionEvent() const {
|
2014-08-04 05:28:49 +00:00
|
|
|
return mClass == eSelectionEventClass;
|
2013-09-24 10:04:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bool WidgetEvent::IsContentCommandEvent() const {
|
2014-08-04 05:28:56 +00:00
|
|
|
return mClass == eContentCommandEventClass;
|
2013-09-24 10:04:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/******************************************************************************
|
|
|
|
* mozilla::WidgetEvent
|
|
|
|
*
|
|
|
|
* Event message checking methods.
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
bool WidgetEvent::HasMouseEventMessage() const {
|
2015-08-22 01:34:51 +00:00
|
|
|
switch (mMessage) {
|
2015-08-28 23:58:30 +00:00
|
|
|
case eMouseDown:
|
2015-08-28 23:58:30 +00:00
|
|
|
case eMouseUp:
|
2015-08-28 23:58:31 +00:00
|
|
|
case eMouseDoubleClick:
|
2015-08-28 23:58:31 +00:00
|
|
|
case eMouseEnterIntoWidget:
|
2015-08-28 23:58:31 +00:00
|
|
|
case eMouseExitFromWidget:
|
2015-08-28 23:58:32 +00:00
|
|
|
case eMouseActivate:
|
2015-08-28 23:58:32 +00:00
|
|
|
case eMouseOver:
|
2015-08-28 23:58:32 +00:00
|
|
|
case eMouseOut:
|
2015-08-28 23:58:32 +00:00
|
|
|
case eMouseHitTest:
|
2015-08-28 23:58:29 +00:00
|
|
|
case eMouseMove:
|
2013-09-24 10:04:16 +00:00
|
|
|
return true;
|
2024-06-14 00:18:46 +00:00
|
|
|
// TODO: Perhaps, we should rename this method.
|
|
|
|
case ePointerClick:
|
|
|
|
case ePointerAuxClick:
|
|
|
|
return true;
|
2013-09-24 10:04:16 +00:00
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Bug 1675847 - part 3: Make `ePointerClick` event dispatchers and handlers use `WidgetPointerEvent` r=smaug,search-reviewers,devtools-reviewers,nchevobbe,jteow
This patch makes the all `ePointerClick` event dispatcher in C++ code use
`WidgetPointerEvent` instead of `WidgetMouseEvent`.
Then, this patch also makes the all `click` event dispatcher in chrome code use
`PointerEvent` instead of `MouseEvent`. For detecting wrong trusted event
dispatching of `click` event, this patch adds assertion into `MouseEvent`.
Therefore, all chrome test dispatchers also changed to use `PointerEvent`.
Finally, this patch includes a change of a WPT. That checks the `pointerId`
caused by executing an access key. In this case, the value should be `-1`
rather than the default value `0` because Pointer Event spec defines so for
synthetic pointer events caused by non-pointing devices [1]. Chrome also
sets it to `-1` and fails [2]. Therefore, the new assertion will pass on both
Firefox and Chrome.
1. https://w3c.github.io/pointerevents/#dom-pointerevent-pointerid
2. https://wpt.fyi/results/uievents/interface/keyboard-accesskey-click-event.html?run_id=5087897523060736&run_id=5136270464647168&run_id=5163620816388096&run_id=5201281304231936
Differential Revision: https://phabricator.services.mozilla.com/D213001
2024-06-14 00:18:47 +00:00
|
|
|
bool WidgetEvent::IsMouseEventClassOrHasClickRelatedPointerEvent() const {
|
|
|
|
return mClass == eMouseEventClass ||
|
|
|
|
IsPointerEventMessageOriginallyMouseEventMessage(mMessage);
|
|
|
|
}
|
|
|
|
|
2013-09-24 10:04:16 +00:00
|
|
|
bool WidgetEvent::HasDragEventMessage() const {
|
2015-08-22 01:34:51 +00:00
|
|
|
switch (mMessage) {
|
2015-09-02 06:08:02 +00:00
|
|
|
case eDragEnter:
|
2015-09-02 06:08:02 +00:00
|
|
|
case eDragOver:
|
2015-09-02 06:08:02 +00:00
|
|
|
case eDragExit:
|
2015-09-02 06:08:02 +00:00
|
|
|
case eDrag:
|
2015-09-02 06:08:02 +00:00
|
|
|
case eDragEnd:
|
2015-09-02 06:08:01 +00:00
|
|
|
case eDragStart:
|
2015-09-02 06:08:01 +00:00
|
|
|
case eDrop:
|
2015-09-02 06:08:01 +00:00
|
|
|
case eDragLeave:
|
2013-09-24 10:04:16 +00:00
|
|
|
return true;
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Bug 1406446 - part 1: InputContextAction should treat focus change during handling a user input as caused by user input even if it's caused by JS r=smaug
Currently, widget doesn't show VKB when input context change is caused by JS.
However, if it's caused by an event handler of a user input, user may expect
to open VKB. For example, if a touch event in fake editor causes moving
focus to actual editable node, user expect to show VKB.
Therefore, InputContextAction should declare two causes. One is unknown but
occurred during handling non-keyboard event. The other is unknown but occurred
during handling keyboard event.
However, EventStateManager doesn't have an API to check if it's being handling
a keyboard event. Therefore, this patch adds it first.
AutoHandlingUserInputStatePusher sends event type to StartHandlingUserInput()
and StopHandlingUserInput() of EventStateManager and sUserKeyboardEventDepth
manages the number of nested keyboard event handling. Therefore,
EventStateManager::IsHandlingKeyboardInput() can return if it's handling a
keyboard event.
IMEStateManager uses this new API to adjust the cause of changes of input
context.
Finally, InputContextAction::IsUserInput() is renamed to IsHandlingUserInput()
for consistency with EventStateManager and starts to return true when the
input context change is caused by script while it's handling a user input.
MozReview-Commit-ID: 5JsLqdqeGah
--HG--
extra : rebase_source : 9fcf7687d1bf90eeebbf6eac62d4488ff64b083c
2017-10-23 17:46:15 +00:00
|
|
|
/* static */
|
|
|
|
bool WidgetEvent::IsKeyEventMessage(EventMessage aMessage) {
|
|
|
|
switch (aMessage) {
|
2015-08-28 23:58:27 +00:00
|
|
|
case eKeyDown:
|
2015-08-28 23:58:27 +00:00
|
|
|
case eKeyPress:
|
2015-08-28 23:58:27 +00:00
|
|
|
case eKeyUp:
|
2016-05-11 12:56:42 +00:00
|
|
|
case eAccessKeyNotFound:
|
2013-09-24 10:04:16 +00:00
|
|
|
return true;
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
bool WidgetEvent::HasIMEEventMessage() const {
|
2015-08-22 01:34:51 +00:00
|
|
|
switch (mMessage) {
|
2015-09-11 12:21:27 +00:00
|
|
|
case eCompositionStart:
|
2015-09-11 12:21:27 +00:00
|
|
|
case eCompositionEnd:
|
2015-09-11 12:21:27 +00:00
|
|
|
case eCompositionUpdate:
|
2015-09-11 12:21:27 +00:00
|
|
|
case eCompositionChange:
|
2015-09-11 12:21:26 +00:00
|
|
|
case eCompositionCommitAsIs:
|
2015-09-11 12:21:27 +00:00
|
|
|
case eCompositionCommit:
|
2013-09-24 10:04:16 +00:00
|
|
|
return true;
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/******************************************************************************
|
|
|
|
* mozilla::WidgetEvent
|
|
|
|
*
|
|
|
|
* Specific event checking methods.
|
|
|
|
******************************************************************************/
|
|
|
|
|
2017-01-19 07:46:59 +00:00
|
|
|
bool WidgetEvent::CanBeSentToRemoteProcess() const {
|
|
|
|
// If this event is explicitly marked as shouldn't be sent to remote process,
|
|
|
|
// just return false.
|
2017-07-05 04:58:41 +00:00
|
|
|
if (IsCrossProcessForwardingStopped()) {
|
2017-01-19 07:46:59 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (mClass == eKeyboardEventClass || mClass == eWheelEventClass) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (mMessage) {
|
|
|
|
case eMouseDown:
|
|
|
|
case eMouseUp:
|
|
|
|
case eMouseMove:
|
2021-12-28 20:41:22 +00:00
|
|
|
case eMouseExploreByTouch:
|
2017-01-19 07:46:59 +00:00
|
|
|
case eContextMenu:
|
|
|
|
case eMouseEnterIntoWidget:
|
|
|
|
case eMouseExitFromWidget:
|
|
|
|
case eMouseTouchDrag:
|
|
|
|
case eTouchStart:
|
|
|
|
case eTouchMove:
|
|
|
|
case eTouchEnd:
|
|
|
|
case eTouchCancel:
|
|
|
|
case eDragOver:
|
|
|
|
case eDragExit:
|
|
|
|
case eDrop:
|
|
|
|
return true;
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-19 09:39:34 +00:00
|
|
|
bool WidgetEvent::WillBeSentToRemoteProcess() const {
|
|
|
|
// This event won't be posted to remote process if it's already explicitly
|
|
|
|
// stopped.
|
|
|
|
if (IsCrossProcessForwardingStopped()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// When mOriginalTarget is nullptr, this method shouldn't be used.
|
|
|
|
if (NS_WARN_IF(!mOriginalTarget)) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2021-11-02 13:03:43 +00:00
|
|
|
return EventStateManager::IsTopLevelRemoteTarget(
|
|
|
|
nsIContent::FromEventTarget(mOriginalTarget));
|
2017-07-19 09:39:34 +00:00
|
|
|
}
|
|
|
|
|
2013-09-24 10:04:16 +00:00
|
|
|
bool WidgetEvent::IsIMERelatedEvent() const {
|
2024-09-11 23:02:22 +00:00
|
|
|
return HasIMEEventMessage() ||
|
|
|
|
(IsQueryContentEvent() && mMessage != eQueryDropTargetHittest) ||
|
|
|
|
IsSelectionEvent();
|
2013-09-24 10:04:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bool WidgetEvent::IsUsingCoordinates() const {
|
2013-10-28 09:03:19 +00:00
|
|
|
const WidgetMouseEvent* mouseEvent = AsMouseEvent();
|
|
|
|
if (mouseEvent) {
|
|
|
|
return !mouseEvent->IsContextMenuKeyEvent();
|
|
|
|
}
|
2013-09-24 10:04:16 +00:00
|
|
|
return !HasKeyEventMessage() && !IsIMERelatedEvent() &&
|
2022-04-27 01:15:29 +00:00
|
|
|
!IsContentCommandEvent();
|
2013-09-24 10:04:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bool WidgetEvent::IsTargetedAtFocusedWindow() const {
|
2013-10-28 09:03:19 +00:00
|
|
|
const WidgetMouseEvent* mouseEvent = AsMouseEvent();
|
|
|
|
if (mouseEvent) {
|
|
|
|
return mouseEvent->IsContextMenuKeyEvent();
|
|
|
|
}
|
2020-12-29 21:19:45 +00:00
|
|
|
return HasKeyEventMessage() || IsIMERelatedEvent() || IsContentCommandEvent();
|
2013-09-24 10:04:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bool WidgetEvent::IsTargetedAtFocusedContent() const {
|
2013-10-28 09:03:19 +00:00
|
|
|
const WidgetMouseEvent* mouseEvent = AsMouseEvent();
|
|
|
|
if (mouseEvent) {
|
|
|
|
return mouseEvent->IsContextMenuKeyEvent();
|
|
|
|
}
|
2020-12-29 21:19:45 +00:00
|
|
|
return HasKeyEventMessage() || IsIMERelatedEvent();
|
2013-09-24 10:04:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bool WidgetEvent::IsAllowedToDispatchDOMEvent() const {
|
2014-08-04 05:28:46 +00:00
|
|
|
switch (mClass) {
|
2014-08-04 05:28:50 +00:00
|
|
|
case eMouseEventClass:
|
2017-01-03 15:55:48 +00:00
|
|
|
if (mMessage == eMouseTouchDrag) {
|
|
|
|
return false;
|
2016-09-20 06:33:08 +00:00
|
|
|
}
|
2019-12-20 07:16:43 +00:00
|
|
|
[[fallthrough]];
|
2014-08-04 05:28:52 +00:00
|
|
|
case ePointerEventClass:
|
2013-09-24 10:04:16 +00:00
|
|
|
// We want synthesized mouse moves to cause mouseover and mouseout
|
2014-04-01 04:09:23 +00:00
|
|
|
// DOM events (EventStateManager::PreHandleEvent), but not mousemove
|
2013-09-24 10:04:16 +00:00
|
|
|
// DOM events.
|
|
|
|
// Synthesized button up events also do not cause DOM events because they
|
2016-04-18 14:09:02 +00:00
|
|
|
// do not have a reliable mRefPoint.
|
2016-05-12 02:36:41 +00:00
|
|
|
return AsMouseEvent()->mReason == WidgetMouseEvent::eReal;
|
2013-09-24 10:04:16 +00:00
|
|
|
|
2014-08-04 05:28:51 +00:00
|
|
|
case eWheelEventClass: {
|
2013-09-24 10:04:16 +00:00
|
|
|
// wheel event whose all delta values are zero by user pref applied, it
|
|
|
|
// shouldn't cause a DOM event.
|
2013-10-18 06:10:20 +00:00
|
|
|
const WidgetWheelEvent* wheelEvent = AsWheelEvent();
|
2016-03-31 09:09:47 +00:00
|
|
|
return wheelEvent->mDeltaX != 0.0 || wheelEvent->mDeltaY != 0.0 ||
|
2016-03-31 09:18:34 +00:00
|
|
|
wheelEvent->mDeltaZ != 0.0;
|
2013-09-24 10:04:16 +00:00
|
|
|
}
|
2017-02-16 07:05:09 +00:00
|
|
|
case eTouchEventClass:
|
|
|
|
return mMessage != eTouchPointerCancel;
|
2014-03-27 13:53:19 +00:00
|
|
|
// Following events are handled in EventStateManager, so, we don't need to
|
|
|
|
// dispatch DOM event for them into the DOM tree.
|
2014-08-04 05:28:49 +00:00
|
|
|
case eQueryContentEventClass:
|
2014-08-04 05:28:49 +00:00
|
|
|
case eSelectionEventClass:
|
2014-08-04 05:28:56 +00:00
|
|
|
case eContentCommandEventClass:
|
2014-03-27 13:53:19 +00:00
|
|
|
return false;
|
|
|
|
|
2013-09-24 10:04:16 +00:00
|
|
|
default:
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-11-11 10:02:37 +00:00
|
|
|
bool WidgetEvent::IsAllowedToDispatchInSystemGroup() const {
|
|
|
|
// We don't expect to implement default behaviors with pointer events because
|
|
|
|
// if we do, prevent default on mouse events can't prevent default behaviors
|
|
|
|
// anymore.
|
Bug 1675847 - part 3: Make `ePointerClick` event dispatchers and handlers use `WidgetPointerEvent` r=smaug,search-reviewers,devtools-reviewers,nchevobbe,jteow
This patch makes the all `ePointerClick` event dispatcher in C++ code use
`WidgetPointerEvent` instead of `WidgetMouseEvent`.
Then, this patch also makes the all `click` event dispatcher in chrome code use
`PointerEvent` instead of `MouseEvent`. For detecting wrong trusted event
dispatching of `click` event, this patch adds assertion into `MouseEvent`.
Therefore, all chrome test dispatchers also changed to use `PointerEvent`.
Finally, this patch includes a change of a WPT. That checks the `pointerId`
caused by executing an access key. In this case, the value should be `-1`
rather than the default value `0` because Pointer Event spec defines so for
synthetic pointer events caused by non-pointing devices [1]. Chrome also
sets it to `-1` and fails [2]. Therefore, the new assertion will pass on both
Firefox and Chrome.
1. https://w3c.github.io/pointerevents/#dom-pointerevent-pointerid
2. https://wpt.fyi/results/uievents/interface/keyboard-accesskey-click-event.html?run_id=5087897523060736&run_id=5136270464647168&run_id=5163620816388096&run_id=5201281304231936
Differential Revision: https://phabricator.services.mozilla.com/D213001
2024-06-14 00:18:47 +00:00
|
|
|
return mClass != ePointerEventClass ||
|
|
|
|
IsPointerEventMessageOriginallyMouseEventMessage(mMessage);
|
2016-11-11 10:02:37 +00:00
|
|
|
}
|
|
|
|
|
2017-08-31 03:14:14 +00:00
|
|
|
bool WidgetEvent::IsBlockedForFingerprintingResistance() const {
|
2018-10-09 11:50:01 +00:00
|
|
|
switch (mClass) {
|
|
|
|
case eKeyboardEventClass: {
|
|
|
|
const WidgetKeyboardEvent* keyboardEvent = AsKeyboardEvent();
|
|
|
|
|
|
|
|
return (keyboardEvent->mKeyNameIndex == KEY_NAME_INDEX_Alt ||
|
|
|
|
keyboardEvent->mKeyNameIndex == KEY_NAME_INDEX_Shift ||
|
|
|
|
keyboardEvent->mKeyNameIndex == KEY_NAME_INDEX_Control ||
|
|
|
|
keyboardEvent->mKeyNameIndex == KEY_NAME_INDEX_AltGraph);
|
|
|
|
}
|
|
|
|
case ePointerEventClass: {
|
Bug 1675847 - part 3: Make `ePointerClick` event dispatchers and handlers use `WidgetPointerEvent` r=smaug,search-reviewers,devtools-reviewers,nchevobbe,jteow
This patch makes the all `ePointerClick` event dispatcher in C++ code use
`WidgetPointerEvent` instead of `WidgetMouseEvent`.
Then, this patch also makes the all `click` event dispatcher in chrome code use
`PointerEvent` instead of `MouseEvent`. For detecting wrong trusted event
dispatching of `click` event, this patch adds assertion into `MouseEvent`.
Therefore, all chrome test dispatchers also changed to use `PointerEvent`.
Finally, this patch includes a change of a WPT. That checks the `pointerId`
caused by executing an access key. In this case, the value should be `-1`
rather than the default value `0` because Pointer Event spec defines so for
synthetic pointer events caused by non-pointing devices [1]. Chrome also
sets it to `-1` and fails [2]. Therefore, the new assertion will pass on both
Firefox and Chrome.
1. https://w3c.github.io/pointerevents/#dom-pointerevent-pointerid
2. https://wpt.fyi/results/uievents/interface/keyboard-accesskey-click-event.html?run_id=5087897523060736&run_id=5136270464647168&run_id=5163620816388096&run_id=5201281304231936
Differential Revision: https://phabricator.services.mozilla.com/D213001
2024-06-14 00:18:47 +00:00
|
|
|
if (IsPointerEventMessageOriginallyMouseEventMessage(mMessage)) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2024-09-10 14:37:50 +00:00
|
|
|
if (SPOOFED_MAX_TOUCH_POINTS > 0) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2018-10-09 11:50:01 +00:00
|
|
|
const WidgetPointerEvent* pointerEvent = AsPointerEvent();
|
|
|
|
|
|
|
|
// We suppress the pointer events if it is not primary for fingerprinting
|
|
|
|
// resistance. It is because of that we want to spoof any pointer event
|
|
|
|
// into a mouse pointer event and the mouse pointer event only has
|
|
|
|
// isPrimary as true.
|
|
|
|
return !pointerEvent->mIsPrimary;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
2017-08-31 03:14:14 +00:00
|
|
|
}
|
|
|
|
|
2023-08-07 05:24:20 +00:00
|
|
|
bool WidgetEvent::AllowFlushingPendingNotifications() const {
|
|
|
|
if (mClass != eQueryContentEventClass) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
// If the dispatcher does not want a flush of pending notifications, it may
|
|
|
|
// be caused by that it's unsafe. Therefore, we should allow handlers to
|
|
|
|
// flush pending things only when the dispatcher requires the latest content
|
|
|
|
// layout.
|
|
|
|
return AsQueryContentEvent()->mNeedsToFlushLayout;
|
|
|
|
}
|
|
|
|
|
Bug 1793267 - Make `PostEventHandler::CheckPointerCaptureState` synthesize `ePointerMove` and `eMouseMove` if nobody captures the pointer anymore r=smaug
When an element starts capturing a pointer, pointer/mouse boundary events are
dispatched by `EventStateManager::PreHandleEvent` [1]. However, when the
capturing element loses the capture, they are not dispatched.
When the pointer capture is implicitly released, the pointer may be over another
document. Therefore, this patch synthesizes an internal `ePointerMove` and
`eMouseMove` on the widget to make `PresShell::HandleEvent` redirects the event
to proper document under the pointer.
Unfortunately, I add 2 manual tests into WPT. The reason is, a drag operation
across document boundary with test driver does not work even if I specify the
pointer position within the parent document coordinates. This is same both on
Firefox and Chrome. Additionally, writing the new tests as a mochitest won't
work too. If I use synthesized mouse events, I see similar failure.
Additionally, when I use native events, it works, but unstable to run on CI.
1. https://searchfox.org/mozilla-central/rev/669fac9888b173c02baa4c036e980c0c204dfe02/dom/events/EventStateManager.cpp#1139-1140
Differential Revision: https://phabricator.services.mozilla.com/D218896
2024-08-20 03:42:26 +00:00
|
|
|
bool WidgetEvent::ShouldIgnoreCapturingContent() const {
|
|
|
|
MOZ_ASSERT(IsUsingCoordinates());
|
|
|
|
|
|
|
|
if (MOZ_UNLIKELY(!IsTrusted())) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return mClass == eMouseEventClass || mClass == ePointerEventClass
|
|
|
|
? AsMouseEvent()->mIgnoreCapturingContent
|
|
|
|
: false;
|
|
|
|
}
|
|
|
|
|
2017-01-17 08:17:06 +00:00
|
|
|
/******************************************************************************
|
|
|
|
* mozilla::WidgetEvent
|
|
|
|
*
|
|
|
|
* Misc methods.
|
|
|
|
******************************************************************************/
|
|
|
|
|
2018-04-05 17:42:41 +00:00
|
|
|
static dom::EventTarget* GetTargetForDOMEvent(dom::EventTarget* aTarget) {
|
2017-01-17 08:17:06 +00:00
|
|
|
return aTarget ? aTarget->GetTargetForDOMEvent() : nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
dom::EventTarget* WidgetEvent::GetDOMEventTarget() const {
|
|
|
|
return GetTargetForDOMEvent(mTarget);
|
|
|
|
}
|
|
|
|
|
|
|
|
dom::EventTarget* WidgetEvent::GetCurrentDOMEventTarget() const {
|
|
|
|
return GetTargetForDOMEvent(mCurrentTarget);
|
|
|
|
}
|
|
|
|
|
|
|
|
dom::EventTarget* WidgetEvent::GetOriginalDOMEventTarget() const {
|
|
|
|
if (mOriginalTarget) {
|
|
|
|
return GetTargetForDOMEvent(mOriginalTarget);
|
|
|
|
}
|
|
|
|
return GetDOMEventTarget();
|
|
|
|
}
|
|
|
|
|
2017-07-10 08:42:01 +00:00
|
|
|
void WidgetEvent::PreventDefault(bool aCalledByDefaultHandler,
|
|
|
|
nsIPrincipal* aPrincipal) {
|
|
|
|
if (mMessage == ePointerDown) {
|
|
|
|
if (aCalledByDefaultHandler) {
|
|
|
|
// Shouldn't prevent default on pointerdown by default handlers to stop
|
|
|
|
// firing legacy mouse events. Use MOZ_ASSERT to catch incorrect usages
|
|
|
|
// in debug builds.
|
|
|
|
MOZ_ASSERT(false);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (aPrincipal) {
|
|
|
|
nsAutoString addonId;
|
|
|
|
Unused << NS_WARN_IF(NS_FAILED(aPrincipal->GetAddonId(addonId)));
|
|
|
|
if (!addonId.IsEmpty()) {
|
|
|
|
// Ignore the case that it's called by a web extension.
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
mFlags.PreventDefault(aCalledByDefaultHandler);
|
|
|
|
}
|
|
|
|
|
2017-11-21 22:25:09 +00:00
|
|
|
bool WidgetEvent::IsUserAction() const {
|
|
|
|
if (!IsTrusted()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
// FYI: eMouseScrollEventClass and ePointerEventClass represent
|
|
|
|
// user action but they are synthesized events.
|
|
|
|
switch (mClass) {
|
|
|
|
case eKeyboardEventClass:
|
|
|
|
case eCompositionEventClass:
|
|
|
|
case eMouseScrollEventClass:
|
|
|
|
case eWheelEventClass:
|
|
|
|
case eGestureNotifyEventClass:
|
|
|
|
case eSimpleGestureEventClass:
|
|
|
|
case eTouchEventClass:
|
|
|
|
case eCommandEventClass:
|
|
|
|
case eContentCommandEventClass:
|
|
|
|
return true;
|
|
|
|
case eMouseEventClass:
|
|
|
|
case eDragEventClass:
|
|
|
|
case ePointerEventClass:
|
|
|
|
return AsMouseEvent()->IsReal();
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-05-22 04:06:05 +00:00
|
|
|
/******************************************************************************
|
|
|
|
* mozilla::WidgetInputEvent
|
|
|
|
******************************************************************************/
|
|
|
|
|
2015-02-19 06:50:19 +00:00
|
|
|
/* static */
|
|
|
|
Modifier WidgetInputEvent::GetModifier(const nsAString& aDOMKeyName) {
|
|
|
|
if (aDOMKeyName.EqualsLiteral("Accel")) {
|
|
|
|
return AccelModifier();
|
|
|
|
}
|
|
|
|
KeyNameIndex keyNameIndex = WidgetKeyboardEvent::GetKeyNameIndex(aDOMKeyName);
|
|
|
|
return WidgetKeyboardEvent::GetModifierForKeyName(keyNameIndex);
|
|
|
|
}
|
|
|
|
|
2014-05-22 04:06:05 +00:00
|
|
|
/* static */
|
|
|
|
Modifier WidgetInputEvent::AccelModifier() {
|
|
|
|
static Modifier sAccelModifier = MODIFIER_NONE;
|
|
|
|
if (sAccelModifier == MODIFIER_NONE) {
|
2023-02-07 16:29:40 +00:00
|
|
|
switch (StaticPrefs::ui_key_accelKey()) {
|
2018-06-25 21:20:54 +00:00
|
|
|
case dom::KeyboardEvent_Binding::DOM_VK_META:
|
2023-08-04 03:29:52 +00:00
|
|
|
case dom::KeyboardEvent_Binding::DOM_VK_WIN:
|
Bug 1266437 - Drop "OS" modifier r=smaug,m_kato,karlt,Gijs
On Windows, Windows logo key was mapped to "OS" modifier, and on Linux,
it's same and the key is called "Super" and "Hyper". That conformed to the
older UI Events spec.
However, UI Events declares that they should be mapped to "Meta" now and Chrome
handles it as the spec in Windows and Linux. Therefore, we should align the
behavior to them.
Note that we've treated the legacy "Meta" modifier on Linux as DOM "Meta"
modifier state, and we'll keep this as-is because in Sun/Solaris keyboard
layout, they keys are mapped to the legacy "Meta".
Finally, the following check only `IsMeta()` but not `IsOS()`. I think that
they should've checked `IsOS()` too. Therefore, they will behave differently
in Windows and Linux.
* https://searchfox.org/mozilla-central/rev/9a4666e63199bd1bcfc9095f6efec3488c358458/dom/base/Element.cpp#3287-3288
* https://searchfox.org/mozilla-central/rev/9a4666e63199bd1bcfc9095f6efec3488c358458/dom/html/HTMLInputElement.cpp#3762-3764
* https://searchfox.org/mozilla-central/rev/9a4666e63199bd1bcfc9095f6efec3488c358458/dom/html/HTMLInputElement.cpp#3796-3806
* https://searchfox.org/mozilla-central/rev/9a4666e63199bd1bcfc9095f6efec3488c358458/dom/html/HTMLLabelElement.cpp#127-128
* https://searchfox.org/mozilla-central/rev/9a4666e63199bd1bcfc9095f6efec3488c358458/widget/gtk/nsGtkKeyUtils.cpp#1461-1462
Note that `KEY_NAME_INDEX_OS` will be removed in the patch for bug 1232918.
Differential Revision: https://phabricator.services.mozilla.com/D183480
2023-08-07 01:03:58 +00:00
|
|
|
sAccelModifier = MODIFIER_META;
|
2023-08-04 03:29:52 +00:00
|
|
|
break;
|
2018-06-25 21:20:54 +00:00
|
|
|
case dom::KeyboardEvent_Binding::DOM_VK_ALT:
|
2014-05-22 04:06:05 +00:00
|
|
|
sAccelModifier = MODIFIER_ALT;
|
|
|
|
break;
|
2018-06-25 21:20:54 +00:00
|
|
|
case dom::KeyboardEvent_Binding::DOM_VK_CONTROL:
|
2014-05-22 04:06:05 +00:00
|
|
|
sAccelModifier = MODIFIER_CONTROL;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
#ifdef XP_MACOSX
|
|
|
|
sAccelModifier = MODIFIER_META;
|
|
|
|
#else
|
|
|
|
sAccelModifier = MODIFIER_CONTROL;
|
|
|
|
#endif
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return sAccelModifier;
|
|
|
|
}
|
|
|
|
|
2024-08-17 07:43:46 +00:00
|
|
|
/******************************************************************************
|
|
|
|
* mozilla::WidgetPointerHelper (MouseEvents.h)
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
// static
|
|
|
|
int32_t WidgetPointerHelper::GetValidTiltValue(int32_t aTilt) {
|
|
|
|
if (MOZ_LIKELY(aTilt >= -90 && aTilt <= 90)) {
|
|
|
|
return aTilt;
|
|
|
|
}
|
|
|
|
while (aTilt > 90) {
|
|
|
|
aTilt -= 180;
|
|
|
|
}
|
|
|
|
while (aTilt < -90) {
|
|
|
|
aTilt += 180;
|
|
|
|
}
|
|
|
|
MOZ_ASSERT(aTilt >= -90 && aTilt <= 90);
|
|
|
|
return aTilt;
|
|
|
|
}
|
|
|
|
|
|
|
|
// static
|
|
|
|
double WidgetPointerHelper::GetValidAltitudeAngle(double aAltitudeAngle) {
|
|
|
|
if (MOZ_LIKELY(aAltitudeAngle >= 0.0 && aAltitudeAngle <= kHalfPi)) {
|
|
|
|
return aAltitudeAngle;
|
|
|
|
}
|
|
|
|
while (aAltitudeAngle > kHalfPi) {
|
|
|
|
aAltitudeAngle -= kHalfPi;
|
|
|
|
}
|
|
|
|
while (aAltitudeAngle < 0.0) {
|
|
|
|
aAltitudeAngle += kHalfPi;
|
|
|
|
}
|
|
|
|
MOZ_ASSERT(aAltitudeAngle >= 0.0 && aAltitudeAngle <= kHalfPi);
|
|
|
|
return aAltitudeAngle;
|
|
|
|
}
|
|
|
|
|
|
|
|
// static
|
|
|
|
double WidgetPointerHelper::GetValidAzimuthAngle(double aAzimuthAngle) {
|
|
|
|
if (MOZ_LIKELY(aAzimuthAngle >= 0.0 && aAzimuthAngle <= kDoublePi)) {
|
|
|
|
return aAzimuthAngle;
|
|
|
|
}
|
|
|
|
while (aAzimuthAngle > kDoublePi) {
|
|
|
|
aAzimuthAngle -= kDoublePi;
|
|
|
|
}
|
|
|
|
while (aAzimuthAngle < 0.0) {
|
|
|
|
aAzimuthAngle += kDoublePi;
|
|
|
|
}
|
|
|
|
MOZ_ASSERT(aAzimuthAngle >= 0.0 && aAzimuthAngle <= kDoublePi);
|
|
|
|
return aAzimuthAngle;
|
|
|
|
}
|
|
|
|
|
|
|
|
// static
|
|
|
|
double WidgetPointerHelper::ComputeAltitudeAngle(int32_t aTiltX,
|
|
|
|
int32_t aTiltY) {
|
|
|
|
// https://w3c.github.io/pointerevents/#converting-between-tiltx-tilty-and-altitudeangle-azimuthangle
|
|
|
|
aTiltX = GetValidTiltValue(aTiltX);
|
|
|
|
aTiltY = GetValidTiltValue(aTiltY);
|
|
|
|
if (std::abs(aTiltX) == 90 || std::abs(aTiltY) == 90) {
|
|
|
|
return 0.0;
|
|
|
|
}
|
|
|
|
const double tiltXRadians = kPi / 180.0 * aTiltX;
|
|
|
|
const double tiltYRadians = kPi / 180.0 * aTiltY;
|
|
|
|
if (!aTiltX) {
|
|
|
|
return kHalfPi - std::abs(tiltYRadians);
|
|
|
|
}
|
|
|
|
if (!aTiltY) {
|
|
|
|
return kHalfPi - std::abs(tiltXRadians);
|
|
|
|
}
|
|
|
|
return std::atan(1.0 / std::sqrt(std::pow(std::tan(tiltXRadians), 2) +
|
|
|
|
std::pow(std::tan(tiltYRadians), 2)));
|
|
|
|
}
|
|
|
|
|
|
|
|
// static
|
|
|
|
double WidgetPointerHelper::ComputeAzimuthAngle(int32_t aTiltX,
|
|
|
|
int32_t aTiltY) {
|
|
|
|
// https://w3c.github.io/pointerevents/#converting-between-tiltx-tilty-and-altitudeangle-azimuthangle
|
|
|
|
aTiltX = GetValidTiltValue(aTiltX);
|
|
|
|
aTiltY = GetValidTiltValue(aTiltY);
|
|
|
|
if (!aTiltX) {
|
|
|
|
if (aTiltY > 0) {
|
|
|
|
return kHalfPi;
|
|
|
|
}
|
|
|
|
return aTiltY < 0 ? 3.0 * kHalfPi : 0.0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!aTiltY) {
|
|
|
|
return aTiltX < 0 ? kPi : 0.0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (std::abs(aTiltX) == 90 || std::abs(aTiltY) == 90) {
|
|
|
|
return 0.0;
|
|
|
|
}
|
|
|
|
|
|
|
|
const double tiltXRadians = kPi / 180.0 * aTiltX;
|
|
|
|
const double tiltYRadians = kPi / 180.0 * aTiltY;
|
|
|
|
const double azimuthAngle =
|
|
|
|
std::atan2(std::tan(tiltYRadians), std::tan(tiltXRadians));
|
|
|
|
return azimuthAngle < 0 ? azimuthAngle + kDoublePi : azimuthAngle;
|
|
|
|
}
|
|
|
|
|
|
|
|
// static
|
|
|
|
double WidgetPointerHelper::ComputeTiltX(double aAltitudeAngle,
|
|
|
|
double aAzimuthAngle) {
|
|
|
|
// https://w3c.github.io/pointerevents/#converting-between-tiltx-tilty-and-altitudeangle-azimuthangle
|
|
|
|
aAltitudeAngle = GetValidAltitudeAngle(aAltitudeAngle);
|
|
|
|
aAzimuthAngle = GetValidAzimuthAngle(aAzimuthAngle);
|
|
|
|
if (aAltitudeAngle == 0.0) {
|
|
|
|
if ((aAzimuthAngle >= 0.0 && aAzimuthAngle < kHalfPi) ||
|
|
|
|
(aAzimuthAngle > 3 * kHalfPi && aAzimuthAngle <= kDoublePi)) {
|
|
|
|
return 90; // pi / 2 * 180 / pi
|
|
|
|
}
|
|
|
|
if (aAzimuthAngle > kHalfPi && aAzimuthAngle < 3 * kHalfPi) {
|
|
|
|
return -90; // -1 * pi / 2 * 180 / pi
|
|
|
|
}
|
|
|
|
MOZ_ASSERT(aAzimuthAngle == kHalfPi || aAzimuthAngle == 3 * kHalfPi);
|
|
|
|
return 0.0;
|
|
|
|
}
|
|
|
|
|
|
|
|
constexpr double radToDeg = 180.0 / kPi;
|
|
|
|
return std::floor(
|
|
|
|
std::atan(std::cos(aAzimuthAngle) / std::tan(aAltitudeAngle)) * radToDeg +
|
|
|
|
0.5);
|
|
|
|
}
|
|
|
|
|
|
|
|
// static
|
|
|
|
double WidgetPointerHelper::ComputeTiltY(double aAltitudeAngle,
|
|
|
|
double aAzimuthAngle) {
|
|
|
|
// https://w3c.github.io/pointerevents/#converting-between-tiltx-tilty-and-altitudeangle-azimuthangle
|
|
|
|
aAltitudeAngle = GetValidAltitudeAngle(aAltitudeAngle);
|
|
|
|
aAzimuthAngle = GetValidAzimuthAngle(aAzimuthAngle);
|
|
|
|
if (aAltitudeAngle == 0.0) {
|
|
|
|
if (aAzimuthAngle > 0.0 && aAzimuthAngle < kPi) {
|
|
|
|
return 90; // pi / 2 * 180 / pi
|
|
|
|
}
|
|
|
|
if (aAzimuthAngle > kPi && aAzimuthAngle < kDoublePi) {
|
|
|
|
return -90; // -1 * pi / 2 * 180 / pi
|
|
|
|
}
|
|
|
|
MOZ_ASSERT(aAzimuthAngle == 0.0 || aAzimuthAngle == kPi ||
|
|
|
|
aAzimuthAngle == kDoublePi);
|
|
|
|
return 0.0;
|
|
|
|
}
|
|
|
|
constexpr double radToDeg = 180.0 / kPi;
|
|
|
|
return std::floor(
|
|
|
|
std::atan(std::sin(aAzimuthAngle) / std::tan(aAltitudeAngle)) * radToDeg +
|
|
|
|
0.5);
|
|
|
|
}
|
|
|
|
|
Bug 1844723 - Make `CreateMouseOrPointerWidgetEvent()` set `mButton` to "not pressed" value and compute `mButtons` if the source event has not been dispatched yet r=edgar,dom-core
`CreateMouseOrPointerWidgetEvent()` is designed to create `mouseenter`,
`mouseover`, `mouseout`, `mouseleave`, `pointerenter`, `pointerover`,
`pointerout` and `pointerleave` from a source event.
They are not button state change events, but the source event may be so.
According to the WPTs ([1], [2]) and the fact that the other browsers pass the
tests, the button state of pointer events of synthesizing events should be
synchronized with what the web apps notified (i.e., previous state of the
source event) if and only if the input source supports hover state and the
source event which changes a button state has not been dispatched into the DOM
yet.
1. https://searchfox.org/mozilla-central/rev/08d53deb2cf587e68d1825082c955e8a1926be73/testing/web-platform/tests/pointerevents/pointerevent_attributes_hoverable_pointers.html#44,51,60,63
2. https://searchfox.org/mozilla-central/rev/08d53deb2cf587e68d1825082c955e8a1926be73/testing/web-platform/tests/pointerevents/pointerevent_attributes_nohover_pointers.html#17,45,47,51
Differential Revision: https://phabricator.services.mozilla.com/D187644
2023-10-10 07:33:05 +00:00
|
|
|
/******************************************************************************
|
|
|
|
* mozilla::WidgetMouseEventBase (MouseEvents.h)
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
bool WidgetMouseEventBase::InputSourceSupportsHover() const {
|
|
|
|
switch (mInputSource) {
|
|
|
|
case dom::MouseEvent_Binding::MOZ_SOURCE_MOUSE:
|
|
|
|
case dom::MouseEvent_Binding::MOZ_SOURCE_PEN:
|
|
|
|
case dom::MouseEvent_Binding::MOZ_SOURCE_ERASER:
|
|
|
|
return true;
|
|
|
|
case dom::MouseEvent_Binding::MOZ_SOURCE_TOUCH:
|
|
|
|
case dom::MouseEvent_Binding::MOZ_SOURCE_UNKNOWN:
|
|
|
|
case dom::MouseEvent_Binding::MOZ_SOURCE_KEYBOARD:
|
|
|
|
case dom::MouseEvent_Binding::MOZ_SOURCE_CURSOR:
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-10-10 12:04:17 +00:00
|
|
|
/******************************************************************************
|
|
|
|
* mozilla::WidgetMouseEvent (MouseEvents.h)
|
|
|
|
******************************************************************************/
|
|
|
|
|
2019-02-25 22:13:48 +00:00
|
|
|
/* static */
|
|
|
|
bool WidgetMouseEvent::IsMiddleClickPasteEnabled() {
|
2018-10-10 12:04:17 +00:00
|
|
|
return Preferences::GetBool("middlemouse.paste", false);
|
|
|
|
}
|
|
|
|
|
2021-03-26 02:06:53 +00:00
|
|
|
#ifdef DEBUG
|
|
|
|
void WidgetMouseEvent::AssertContextMenuEventButtonConsistency() const {
|
|
|
|
if (mMessage != eContextMenu) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2024-09-02 02:50:04 +00:00
|
|
|
if (mInputSource == dom::MouseEvent_Binding::MOZ_SOURCE_TOUCH) {
|
|
|
|
NS_WARNING_ASSERTION(mButton == MouseButton::ePrimary,
|
|
|
|
"eContextMenu events by touch trigger should use "
|
|
|
|
"primary mouse button / touch contact");
|
|
|
|
} else if (mContextMenuTrigger == eNormal) {
|
2021-03-26 02:06:53 +00:00
|
|
|
NS_WARNING_ASSERTION(mButton == MouseButton::eSecondary,
|
|
|
|
"eContextMenu events with eNormal trigger should use "
|
|
|
|
"secondary mouse button");
|
|
|
|
} else {
|
|
|
|
NS_WARNING_ASSERTION(mButton == MouseButton::ePrimary,
|
|
|
|
"eContextMenu events with non-eNormal trigger should "
|
|
|
|
"use primary mouse button");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (mContextMenuTrigger == eControlClick) {
|
|
|
|
NS_WARNING_ASSERTION(IsControl(),
|
|
|
|
"eContextMenu events with eControlClick trigger "
|
|
|
|
"should return true from IsControl()");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2019-12-21 12:27:06 +00:00
|
|
|
/******************************************************************************
|
|
|
|
* mozilla::WidgetDragEvent (MouseEvents.h)
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
void WidgetDragEvent::InitDropEffectForTests() {
|
|
|
|
MOZ_ASSERT(mFlags.mIsSynthesizedForTests);
|
2024-07-04 07:48:04 +00:00
|
|
|
MOZ_ASSERT(mWidget);
|
2019-12-21 12:27:06 +00:00
|
|
|
|
2024-07-04 07:48:04 +00:00
|
|
|
nsCOMPtr<nsIDragSession> session = nsContentUtils::GetDragSession(mWidget);
|
2019-12-21 12:27:06 +00:00
|
|
|
if (NS_WARN_IF(!session)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t effectAllowed = session->GetEffectAllowedForTests();
|
|
|
|
uint32_t desiredDropEffect = nsIDragService::DRAGDROP_ACTION_NONE;
|
|
|
|
#ifdef XP_MACOSX
|
|
|
|
if (IsAlt()) {
|
|
|
|
desiredDropEffect = IsMeta() ? nsIDragService::DRAGDROP_ACTION_LINK
|
|
|
|
: nsIDragService::DRAGDROP_ACTION_COPY;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
// On Linux, we know user's intention from API, but we should use
|
|
|
|
// same modifiers as Windows for tests because GNOME on Ubuntu use
|
|
|
|
// them and that makes each test simpler.
|
|
|
|
if (IsControl()) {
|
|
|
|
desiredDropEffect = IsShift() ? nsIDragService::DRAGDROP_ACTION_LINK
|
|
|
|
: nsIDragService::DRAGDROP_ACTION_COPY;
|
|
|
|
} else if (IsShift()) {
|
|
|
|
desiredDropEffect = nsIDragService::DRAGDROP_ACTION_MOVE;
|
|
|
|
}
|
|
|
|
#endif // #ifdef XP_MACOSX #else
|
|
|
|
// First, use modifier state for preferring action which is explicitly
|
|
|
|
// specified by the synthesizer.
|
|
|
|
if (!(desiredDropEffect &= effectAllowed)) {
|
|
|
|
// Otherwise, use an action which is allowed at starting the session.
|
|
|
|
desiredDropEffect = effectAllowed;
|
|
|
|
}
|
|
|
|
if (desiredDropEffect & nsIDragService::DRAGDROP_ACTION_MOVE) {
|
|
|
|
session->SetDragAction(nsIDragService::DRAGDROP_ACTION_MOVE);
|
|
|
|
} else if (desiredDropEffect & nsIDragService::DRAGDROP_ACTION_COPY) {
|
|
|
|
session->SetDragAction(nsIDragService::DRAGDROP_ACTION_COPY);
|
|
|
|
} else if (desiredDropEffect & nsIDragService::DRAGDROP_ACTION_LINK) {
|
|
|
|
session->SetDragAction(nsIDragService::DRAGDROP_ACTION_LINK);
|
|
|
|
} else {
|
|
|
|
session->SetDragAction(nsIDragService::DRAGDROP_ACTION_NONE);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-01-27 06:09:13 +00:00
|
|
|
/******************************************************************************
|
|
|
|
* mozilla::WidgetWheelEvent (MouseEvents.h)
|
|
|
|
******************************************************************************/
|
|
|
|
|
2019-02-25 22:13:48 +00:00
|
|
|
/* static */
|
|
|
|
double WidgetWheelEvent::ComputeOverriddenDelta(double aDelta,
|
|
|
|
bool aIsForVertical) {
|
2021-05-14 17:44:29 +00:00
|
|
|
if (!StaticPrefs::mousewheel_system_scroll_override_enabled()) {
|
2016-01-27 06:09:13 +00:00
|
|
|
return aDelta;
|
|
|
|
}
|
2019-06-27 07:14:02 +00:00
|
|
|
int32_t intFactor =
|
|
|
|
aIsForVertical
|
2021-05-14 17:44:29 +00:00
|
|
|
? StaticPrefs::mousewheel_system_scroll_override_vertical_factor()
|
|
|
|
: StaticPrefs::mousewheel_system_scroll_override_horizontal_factor();
|
2016-01-27 06:09:13 +00:00
|
|
|
// Making the scroll speed slower doesn't make sense. So, ignore odd factor
|
|
|
|
// which is less than 1.0.
|
|
|
|
if (intFactor <= 100) {
|
|
|
|
return aDelta;
|
|
|
|
}
|
|
|
|
double factor = static_cast<double>(intFactor) / 100;
|
|
|
|
return aDelta * factor;
|
|
|
|
}
|
|
|
|
|
|
|
|
double WidgetWheelEvent::OverriddenDeltaX() const {
|
2021-05-14 17:44:29 +00:00
|
|
|
if (!mAllowToOverrideSystemScrollSpeed ||
|
|
|
|
mDeltaMode != dom::WheelEvent_Binding::DOM_DELTA_LINE ||
|
|
|
|
mCustomizedByUserPrefs) {
|
2016-03-31 09:55:59 +00:00
|
|
|
return mDeltaX;
|
2016-01-27 06:09:13 +00:00
|
|
|
}
|
2016-03-31 09:55:59 +00:00
|
|
|
return ComputeOverriddenDelta(mDeltaX, false);
|
2016-01-27 06:09:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
double WidgetWheelEvent::OverriddenDeltaY() const {
|
2021-05-14 17:44:29 +00:00
|
|
|
if (!mAllowToOverrideSystemScrollSpeed ||
|
|
|
|
mDeltaMode != dom::WheelEvent_Binding::DOM_DELTA_LINE ||
|
|
|
|
mCustomizedByUserPrefs) {
|
2016-03-31 09:09:47 +00:00
|
|
|
return mDeltaY;
|
2016-01-27 06:09:13 +00:00
|
|
|
}
|
2016-03-31 09:09:47 +00:00
|
|
|
return ComputeOverriddenDelta(mDeltaY, true);
|
2016-01-27 06:09:13 +00:00
|
|
|
}
|
|
|
|
|
2014-01-08 16:45:30 +00:00
|
|
|
/******************************************************************************
|
|
|
|
* mozilla::WidgetKeyboardEvent (TextEvents.h)
|
|
|
|
******************************************************************************/
|
|
|
|
|
2016-07-20 04:07:53 +00:00
|
|
|
#define NS_DEFINE_KEYNAME(aCPPName, aDOMKeyName) (u"" aDOMKeyName),
|
2016-03-11 02:18:39 +00:00
|
|
|
const char16_t* const WidgetKeyboardEvent::kKeyNames[] = {
|
2015-02-19 06:50:19 +00:00
|
|
|
#include "mozilla/KeyNameList.h"
|
|
|
|
};
|
|
|
|
#undef NS_DEFINE_KEYNAME
|
|
|
|
|
|
|
|
#define NS_DEFINE_PHYSICAL_KEY_CODE_NAME(aCPPName, aDOMCodeName) \
|
2016-07-20 04:07:53 +00:00
|
|
|
(u"" aDOMCodeName),
|
2016-03-11 02:18:39 +00:00
|
|
|
const char16_t* const WidgetKeyboardEvent::kCodeNames[] = {
|
2015-02-19 06:50:19 +00:00
|
|
|
#include "mozilla/PhysicalKeyCodeNameList.h"
|
|
|
|
};
|
|
|
|
#undef NS_DEFINE_PHYSICAL_KEY_CODE_NAME
|
|
|
|
|
|
|
|
WidgetKeyboardEvent::KeyNameIndexHashtable*
|
|
|
|
WidgetKeyboardEvent::sKeyNameIndexHashtable = nullptr;
|
|
|
|
WidgetKeyboardEvent::CodeNameIndexHashtable*
|
|
|
|
WidgetKeyboardEvent::sCodeNameIndexHashtable = nullptr;
|
|
|
|
|
Bug 1685491 - part 5: Move the code remapping arrow keys in vertical content to `NativeKeyBindings` r=smaug,jfkthame
Currently, this feature is implemented only on Linux and macOS (see also
bug 1077515 and bug 1301497), and the code is really similar each other.
Additionally, it always tries to query selection to check whether the caret is
in vertical content or not if arrow keys are pressed. For avoiding a lot of
query, this patch makes `TextEventDispatcher` cache writing mode at every
selection change notification. However, unfortunately, it's not available when
non-editable content has focus, but it should be out of scope of this bug since
it requires a lot of changes.
Anyway, with this patch, we can write a mochitest only on Linux and macOS.
The following patch adds a test for this as a fix of bug 1103374.
Differential Revision: https://phabricator.services.mozilla.com/D102881
2021-02-02 03:29:31 +00:00
|
|
|
void WidgetKeyboardEvent::InitAllEditCommands(
|
|
|
|
const Maybe<WritingMode>& aWritingMode) {
|
Bug 1685491 - part.1: Map typical commands to synthesized keyboard events for test on Linux and macOS r=smaug,remote-protocol-reviewers
Currently, we don't allow keyboard events synthesized for tests retrieve native
key bindings in content process. However, due to this, we cannot test keyboard
navigation, deleting per word, etc on Linux and macOS either with mochitest
or WPT. For making better compatibility with the other browsers, we should
write WPT more with the test driver. Therefore, we should allow keyboard
events synthesized for tests retrieve native key bindings.
On the other hand, if we make them retrieve customized keyboard shortcuts
in the environment, some developers may not be able to run tests locally without
resetting their customization. Therefore, this patch makes `NativeKeyBindings`
set "standard" shortcut keys on the platform instead of retrieving actual
shortcut key results.
If referring the default shortcut key bindings is not good thing for
WebDriver/CDP, perhaps, `TextInputProcessor` should have a new flag which can
refer customized shortcut keys even in content process. But I think that it
should be done in another bug because some edit commands are mapped forcibly
like this patch.
https://searchfox.org/mozilla-central/rev/c03e8de87cdb0ce0378c0886d3c0ce8bbf9dc44e/remote/domains/parent/Input.jsm#82-102
Differential Revision: https://phabricator.services.mozilla.com/D102877
2021-02-02 03:02:30 +00:00
|
|
|
// If this event is synthesized for tests, we don't need to retrieve the
|
|
|
|
// command via the main process. So, we don't need widget and can trust
|
|
|
|
// the event.
|
|
|
|
if (!mFlags.mIsSynthesizedForTests) {
|
|
|
|
// If the event was created without widget, e.g., created event in chrome
|
|
|
|
// script, this shouldn't execute native key bindings.
|
|
|
|
if (NS_WARN_IF(!mWidget)) {
|
|
|
|
return;
|
|
|
|
}
|
2017-05-19 08:24:20 +00:00
|
|
|
|
Bug 1685491 - part.1: Map typical commands to synthesized keyboard events for test on Linux and macOS r=smaug,remote-protocol-reviewers
Currently, we don't allow keyboard events synthesized for tests retrieve native
key bindings in content process. However, due to this, we cannot test keyboard
navigation, deleting per word, etc on Linux and macOS either with mochitest
or WPT. For making better compatibility with the other browsers, we should
write WPT more with the test driver. Therefore, we should allow keyboard
events synthesized for tests retrieve native key bindings.
On the other hand, if we make them retrieve customized keyboard shortcuts
in the environment, some developers may not be able to run tests locally without
resetting their customization. Therefore, this patch makes `NativeKeyBindings`
set "standard" shortcut keys on the platform instead of retrieving actual
shortcut key results.
If referring the default shortcut key bindings is not good thing for
WebDriver/CDP, perhaps, `TextInputProcessor` should have a new flag which can
refer customized shortcut keys even in content process. But I think that it
should be done in another bug because some edit commands are mapped forcibly
like this patch.
https://searchfox.org/mozilla-central/rev/c03e8de87cdb0ce0378c0886d3c0ce8bbf9dc44e/remote/domains/parent/Input.jsm#82-102
Differential Revision: https://phabricator.services.mozilla.com/D102877
2021-02-02 03:02:30 +00:00
|
|
|
// This event should be trusted event here and we shouldn't expose native
|
|
|
|
// key binding information to web contents with untrusted events.
|
|
|
|
if (NS_WARN_IF(!IsTrusted())) {
|
|
|
|
return;
|
|
|
|
}
|
2017-05-19 08:24:20 +00:00
|
|
|
|
Bug 1685491 - part.1: Map typical commands to synthesized keyboard events for test on Linux and macOS r=smaug,remote-protocol-reviewers
Currently, we don't allow keyboard events synthesized for tests retrieve native
key bindings in content process. However, due to this, we cannot test keyboard
navigation, deleting per word, etc on Linux and macOS either with mochitest
or WPT. For making better compatibility with the other browsers, we should
write WPT more with the test driver. Therefore, we should allow keyboard
events synthesized for tests retrieve native key bindings.
On the other hand, if we make them retrieve customized keyboard shortcuts
in the environment, some developers may not be able to run tests locally without
resetting their customization. Therefore, this patch makes `NativeKeyBindings`
set "standard" shortcut keys on the platform instead of retrieving actual
shortcut key results.
If referring the default shortcut key bindings is not good thing for
WebDriver/CDP, perhaps, `TextInputProcessor` should have a new flag which can
refer customized shortcut keys even in content process. But I think that it
should be done in another bug because some edit commands are mapped forcibly
like this patch.
https://searchfox.org/mozilla-central/rev/c03e8de87cdb0ce0378c0886d3c0ce8bbf9dc44e/remote/domains/parent/Input.jsm#82-102
Differential Revision: https://phabricator.services.mozilla.com/D102877
2021-02-02 03:02:30 +00:00
|
|
|
MOZ_ASSERT(
|
|
|
|
XRE_IsParentProcess(),
|
|
|
|
"It's too expensive to retrieve all edit commands from remote process");
|
|
|
|
MOZ_ASSERT(!AreAllEditCommandsInitialized(),
|
|
|
|
"Shouldn't be called two or more times");
|
|
|
|
}
|
2017-05-19 08:24:20 +00:00
|
|
|
|
Bug 1685491 - part 5: Move the code remapping arrow keys in vertical content to `NativeKeyBindings` r=smaug,jfkthame
Currently, this feature is implemented only on Linux and macOS (see also
bug 1077515 and bug 1301497), and the code is really similar each other.
Additionally, it always tries to query selection to check whether the caret is
in vertical content or not if arrow keys are pressed. For avoiding a lot of
query, this patch makes `TextEventDispatcher` cache writing mode at every
selection change notification. However, unfortunately, it's not available when
non-editable content has focus, but it should be out of scope of this bug since
it requires a lot of changes.
Anyway, with this patch, we can write a mochitest only on Linux and macOS.
The following patch adds a test for this as a fix of bug 1103374.
Differential Revision: https://phabricator.services.mozilla.com/D102881
2021-02-02 03:29:31 +00:00
|
|
|
DebugOnly<bool> okIgnored = InitEditCommandsFor(
|
2022-02-15 08:00:05 +00:00
|
|
|
NativeKeyBindingsType::SingleLineEditor, aWritingMode);
|
|
|
|
NS_WARNING_ASSERTION(okIgnored,
|
|
|
|
"InitEditCommandsFor(NativeKeyBindingsType::"
|
|
|
|
"SingleLineEditor) failed, but ignored");
|
|
|
|
okIgnored =
|
|
|
|
InitEditCommandsFor(NativeKeyBindingsType::MultiLineEditor, aWritingMode);
|
|
|
|
NS_WARNING_ASSERTION(okIgnored,
|
|
|
|
"InitEditCommandsFor(NativeKeyBindingsType::"
|
|
|
|
"MultiLineEditor) failed, but ignored");
|
|
|
|
okIgnored =
|
|
|
|
InitEditCommandsFor(NativeKeyBindingsType::RichTextEditor, aWritingMode);
|
|
|
|
NS_WARNING_ASSERTION(okIgnored,
|
|
|
|
"InitEditCommandsFor(NativeKeyBindingsType::"
|
|
|
|
"RichTextEditor) failed, but ignored");
|
2019-11-08 11:32:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bool WidgetKeyboardEvent::InitEditCommandsFor(
|
2022-02-15 08:00:05 +00:00
|
|
|
NativeKeyBindingsType aType, const Maybe<WritingMode>& aWritingMode) {
|
2017-05-19 07:50:30 +00:00
|
|
|
bool& initialized = IsEditCommandsInitializedRef(aType);
|
|
|
|
if (initialized) {
|
2019-11-08 11:32:51 +00:00
|
|
|
return true;
|
2017-05-19 07:50:30 +00:00
|
|
|
}
|
|
|
|
nsTArray<CommandInt>& commands = EditCommandsRef(aType);
|
Bug 1685491 - part.1: Map typical commands to synthesized keyboard events for test on Linux and macOS r=smaug,remote-protocol-reviewers
Currently, we don't allow keyboard events synthesized for tests retrieve native
key bindings in content process. However, due to this, we cannot test keyboard
navigation, deleting per word, etc on Linux and macOS either with mochitest
or WPT. For making better compatibility with the other browsers, we should
write WPT more with the test driver. Therefore, we should allow keyboard
events synthesized for tests retrieve native key bindings.
On the other hand, if we make them retrieve customized keyboard shortcuts
in the environment, some developers may not be able to run tests locally without
resetting their customization. Therefore, this patch makes `NativeKeyBindings`
set "standard" shortcut keys on the platform instead of retrieving actual
shortcut key results.
If referring the default shortcut key bindings is not good thing for
WebDriver/CDP, perhaps, `TextInputProcessor` should have a new flag which can
refer customized shortcut keys even in content process. But I think that it
should be done in another bug because some edit commands are mapped forcibly
like this patch.
https://searchfox.org/mozilla-central/rev/c03e8de87cdb0ce0378c0886d3c0ce8bbf9dc44e/remote/domains/parent/Input.jsm#82-102
Differential Revision: https://phabricator.services.mozilla.com/D102877
2021-02-02 03:02:30 +00:00
|
|
|
|
|
|
|
// If this event is synthesized for tests, we shouldn't access customized
|
|
|
|
// shortcut settings of the environment. Therefore, we don't need to check
|
|
|
|
// whether `widget` is set or not. And we can treat synthesized events are
|
|
|
|
// always trusted.
|
|
|
|
if (mFlags.mIsSynthesizedForTests) {
|
|
|
|
MOZ_DIAGNOSTIC_ASSERT(IsTrusted());
|
|
|
|
#if defined(MOZ_WIDGET_GTK) || defined(XP_MACOSX)
|
|
|
|
// TODO: We should implement `NativeKeyBindings` for Windows and Android
|
|
|
|
// too in bug 1301497 for getting rid of the #if.
|
Bug 1685491 - part 5: Move the code remapping arrow keys in vertical content to `NativeKeyBindings` r=smaug,jfkthame
Currently, this feature is implemented only on Linux and macOS (see also
bug 1077515 and bug 1301497), and the code is really similar each other.
Additionally, it always tries to query selection to check whether the caret is
in vertical content or not if arrow keys are pressed. For avoiding a lot of
query, this patch makes `TextEventDispatcher` cache writing mode at every
selection change notification. However, unfortunately, it's not available when
non-editable content has focus, but it should be out of scope of this bug since
it requires a lot of changes.
Anyway, with this patch, we can write a mochitest only on Linux and macOS.
The following patch adds a test for this as a fix of bug 1103374.
Differential Revision: https://phabricator.services.mozilla.com/D102881
2021-02-02 03:29:31 +00:00
|
|
|
widget::NativeKeyBindings::GetEditCommandsForTests(aType, *this,
|
|
|
|
aWritingMode, commands);
|
Bug 1685491 - part.1: Map typical commands to synthesized keyboard events for test on Linux and macOS r=smaug,remote-protocol-reviewers
Currently, we don't allow keyboard events synthesized for tests retrieve native
key bindings in content process. However, due to this, we cannot test keyboard
navigation, deleting per word, etc on Linux and macOS either with mochitest
or WPT. For making better compatibility with the other browsers, we should
write WPT more with the test driver. Therefore, we should allow keyboard
events synthesized for tests retrieve native key bindings.
On the other hand, if we make them retrieve customized keyboard shortcuts
in the environment, some developers may not be able to run tests locally without
resetting their customization. Therefore, this patch makes `NativeKeyBindings`
set "standard" shortcut keys on the platform instead of retrieving actual
shortcut key results.
If referring the default shortcut key bindings is not good thing for
WebDriver/CDP, perhaps, `TextInputProcessor` should have a new flag which can
refer customized shortcut keys even in content process. But I think that it
should be done in another bug because some edit commands are mapped forcibly
like this patch.
https://searchfox.org/mozilla-central/rev/c03e8de87cdb0ce0378c0886d3c0ce8bbf9dc44e/remote/domains/parent/Input.jsm#82-102
Differential Revision: https://phabricator.services.mozilla.com/D102877
2021-02-02 03:02:30 +00:00
|
|
|
#endif
|
|
|
|
initialized = true;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (NS_WARN_IF(!mWidget) || NS_WARN_IF(!IsTrusted())) {
|
|
|
|
return false;
|
|
|
|
}
|
Bug 1685491 - part 5: Move the code remapping arrow keys in vertical content to `NativeKeyBindings` r=smaug,jfkthame
Currently, this feature is implemented only on Linux and macOS (see also
bug 1077515 and bug 1301497), and the code is really similar each other.
Additionally, it always tries to query selection to check whether the caret is
in vertical content or not if arrow keys are pressed. For avoiding a lot of
query, this patch makes `TextEventDispatcher` cache writing mode at every
selection change notification. However, unfortunately, it's not available when
non-editable content has focus, but it should be out of scope of this bug since
it requires a lot of changes.
Anyway, with this patch, we can write a mochitest only on Linux and macOS.
The following patch adds a test for this as a fix of bug 1103374.
Differential Revision: https://phabricator.services.mozilla.com/D102881
2021-02-02 03:29:31 +00:00
|
|
|
// `nsIWidget::GetEditCommands()` will retrieve `WritingMode` at selection
|
|
|
|
// again, but it should be almost zero-cost since `TextEventDispatcher`
|
|
|
|
// caches the value.
|
|
|
|
nsCOMPtr<nsIWidget> widget = mWidget;
|
|
|
|
initialized = widget->GetEditCommands(aType, *this, commands);
|
2019-11-08 11:32:51 +00:00
|
|
|
return initialized;
|
2017-05-19 07:50:30 +00:00
|
|
|
}
|
|
|
|
|
2022-02-15 08:00:05 +00:00
|
|
|
bool WidgetKeyboardEvent::ExecuteEditCommands(NativeKeyBindingsType aType,
|
|
|
|
DoCommandCallback aCallback,
|
|
|
|
void* aCallbackData) {
|
2017-05-19 07:50:30 +00:00
|
|
|
// If the event was created without widget, e.g., created event in chrome
|
|
|
|
// script, this shouldn't execute native key bindings.
|
|
|
|
if (NS_WARN_IF(!mWidget)) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// This event should be trusted event here and we shouldn't expose native
|
|
|
|
// key binding information to web contents with untrusted events.
|
|
|
|
if (NS_WARN_IF(!IsTrusted())) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
Bug 1685491 - part 5: Move the code remapping arrow keys in vertical content to `NativeKeyBindings` r=smaug,jfkthame
Currently, this feature is implemented only on Linux and macOS (see also
bug 1077515 and bug 1301497), and the code is really similar each other.
Additionally, it always tries to query selection to check whether the caret is
in vertical content or not if arrow keys are pressed. For avoiding a lot of
query, this patch makes `TextEventDispatcher` cache writing mode at every
selection change notification. However, unfortunately, it's not available when
non-editable content has focus, but it should be out of scope of this bug since
it requires a lot of changes.
Anyway, with this patch, we can write a mochitest only on Linux and macOS.
The following patch adds a test for this as a fix of bug 1103374.
Differential Revision: https://phabricator.services.mozilla.com/D102881
2021-02-02 03:29:31 +00:00
|
|
|
if (!IsEditCommandsInitializedRef(aType)) {
|
|
|
|
Maybe<WritingMode> writingMode;
|
|
|
|
if (RefPtr<widget::TextEventDispatcher> textEventDispatcher =
|
|
|
|
mWidget->GetTextEventDispatcher()) {
|
2022-02-15 08:00:06 +00:00
|
|
|
writingMode = textEventDispatcher->MaybeQueryWritingModeAtSelection();
|
Bug 1685491 - part 5: Move the code remapping arrow keys in vertical content to `NativeKeyBindings` r=smaug,jfkthame
Currently, this feature is implemented only on Linux and macOS (see also
bug 1077515 and bug 1301497), and the code is really similar each other.
Additionally, it always tries to query selection to check whether the caret is
in vertical content or not if arrow keys are pressed. For avoiding a lot of
query, this patch makes `TextEventDispatcher` cache writing mode at every
selection change notification. However, unfortunately, it's not available when
non-editable content has focus, but it should be out of scope of this bug since
it requires a lot of changes.
Anyway, with this patch, we can write a mochitest only on Linux and macOS.
The following patch adds a test for this as a fix of bug 1103374.
Differential Revision: https://phabricator.services.mozilla.com/D102881
2021-02-02 03:29:31 +00:00
|
|
|
}
|
|
|
|
if (NS_WARN_IF(!InitEditCommandsFor(aType, writingMode))) {
|
|
|
|
return false;
|
|
|
|
}
|
2019-11-08 11:32:51 +00:00
|
|
|
}
|
2017-05-19 07:50:30 +00:00
|
|
|
|
|
|
|
const nsTArray<CommandInt>& commands = EditCommandsRef(aType);
|
|
|
|
if (commands.IsEmpty()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (CommandInt command : commands) {
|
|
|
|
aCallback(static_cast<Command>(command), aCallbackData);
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-02-19 06:50:18 +00:00
|
|
|
bool WidgetKeyboardEvent::ShouldCauseKeypressEvents() const {
|
2016-03-16 04:50:01 +00:00
|
|
|
// Currently, we don't dispatch keypress events of modifier keys and
|
|
|
|
// dead keys.
|
2015-02-19 06:50:18 +00:00
|
|
|
switch (mKeyNameIndex) {
|
|
|
|
case KEY_NAME_INDEX_Alt:
|
|
|
|
case KEY_NAME_INDEX_AltGraph:
|
|
|
|
case KEY_NAME_INDEX_CapsLock:
|
|
|
|
case KEY_NAME_INDEX_Control:
|
|
|
|
case KEY_NAME_INDEX_Fn:
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_FnLock:
|
2015-02-19 06:50:18 +00:00
|
|
|
// case KEY_NAME_INDEX_Hyper:
|
|
|
|
case KEY_NAME_INDEX_Meta:
|
|
|
|
case KEY_NAME_INDEX_NumLock:
|
|
|
|
case KEY_NAME_INDEX_ScrollLock:
|
|
|
|
case KEY_NAME_INDEX_Shift:
|
|
|
|
// case KEY_NAME_INDEX_Super:
|
|
|
|
case KEY_NAME_INDEX_Symbol:
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_SymbolLock:
|
2016-03-16 04:50:01 +00:00
|
|
|
case KEY_NAME_INDEX_Dead:
|
2015-02-19 06:50:18 +00:00
|
|
|
return false;
|
|
|
|
default:
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-03-18 02:22:37 +00:00
|
|
|
static bool HasASCIIDigit(const ShortcutKeyCandidateArray& aCandidates) {
|
|
|
|
for (uint32_t i = 0; i < aCandidates.Length(); ++i) {
|
|
|
|
uint32_t ch = aCandidates[i].mCharCode;
|
|
|
|
if (ch >= '0' && ch <= '9') return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool CharsCaseInsensitiveEqual(uint32_t aChar1, uint32_t aChar2) {
|
|
|
|
return aChar1 == aChar2 || (IS_IN_BMP(aChar1) && IS_IN_BMP(aChar2) &&
|
|
|
|
ToLowerCase(static_cast<char16_t>(aChar1)) ==
|
|
|
|
ToLowerCase(static_cast<char16_t>(aChar2)));
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool IsCaseChangeableChar(uint32_t aChar) {
|
|
|
|
return IS_IN_BMP(aChar) && ToLowerCase(static_cast<char16_t>(aChar)) !=
|
|
|
|
ToUpperCase(static_cast<char16_t>(aChar));
|
|
|
|
}
|
|
|
|
|
|
|
|
void WidgetKeyboardEvent::GetShortcutKeyCandidates(
|
2017-06-05 23:09:40 +00:00
|
|
|
ShortcutKeyCandidateArray& aCandidates) const {
|
2016-03-18 02:22:37 +00:00
|
|
|
MOZ_ASSERT(aCandidates.IsEmpty(), "aCandidates must be empty");
|
|
|
|
|
2023-08-09 04:47:06 +00:00
|
|
|
using ShiftState = ShortcutKeyCandidate::ShiftState;
|
|
|
|
using SkipIfEarlierHandlerDisabled =
|
|
|
|
ShortcutKeyCandidate::SkipIfEarlierHandlerDisabled;
|
|
|
|
|
2016-03-18 02:22:37 +00:00
|
|
|
// ShortcutKeyCandidate::mCharCode is a candidate charCode.
|
2023-08-09 04:47:06 +00:00
|
|
|
// ShortcutKeyCandidate::mShiftState means the mCharCode should be tried to
|
|
|
|
// execute a command with/without shift key state. If this is Ignorable,
|
|
|
|
// the shifted key state should be ignored. Otherwise, don't ignore the state.
|
2016-03-18 02:22:37 +00:00
|
|
|
// the priority of the charCodes are (shift key is not pressed):
|
2023-08-09 04:47:06 +00:00
|
|
|
// 0: PseudoCharCode()/ShiftState::MatchExactly,
|
|
|
|
// 1: unshiftedCharCodes[0]/ShiftState::MatchExactly,
|
|
|
|
// 2: unshiftedCharCodes[1]/ShiftState::MatchExactly...
|
2016-03-18 02:22:37 +00:00
|
|
|
// the priority of the charCodes are (shift key is pressed):
|
2023-08-09 04:47:06 +00:00
|
|
|
// 0: PseudoCharCode()/ShiftState::MatchExactly,
|
|
|
|
// 1: shiftedCharCodes[0]/ShiftState::MatchExactly,
|
|
|
|
// 2: shiftedCharCodes[0]/ShiftState::Ignorable,
|
|
|
|
// 3: shiftedCharCodes[1]/ShiftState::MatchExactly,
|
|
|
|
// 4: shiftedCharCodes[1]/ShiftState::Ignorable...
|
2016-03-19 11:57:11 +00:00
|
|
|
uint32_t pseudoCharCode = PseudoCharCode();
|
|
|
|
if (pseudoCharCode) {
|
2023-08-09 04:47:06 +00:00
|
|
|
ShortcutKeyCandidate key(pseudoCharCode, ShiftState::MatchExactly,
|
|
|
|
SkipIfEarlierHandlerDisabled::No);
|
2016-03-18 02:22:37 +00:00
|
|
|
aCandidates.AppendElement(key);
|
|
|
|
}
|
|
|
|
|
2016-05-12 08:57:21 +00:00
|
|
|
uint32_t len = mAlternativeCharCodes.Length();
|
2016-03-18 02:22:37 +00:00
|
|
|
if (!IsShift()) {
|
|
|
|
for (uint32_t i = 0; i < len; ++i) {
|
2016-05-12 08:57:21 +00:00
|
|
|
uint32_t ch = mAlternativeCharCodes[i].mUnshiftedCharCode;
|
2016-03-19 11:57:11 +00:00
|
|
|
if (!ch || ch == pseudoCharCode) {
|
2016-03-18 02:22:37 +00:00
|
|
|
continue;
|
|
|
|
}
|
2023-08-09 04:47:06 +00:00
|
|
|
ShortcutKeyCandidate key(ch, ShiftState::MatchExactly,
|
|
|
|
SkipIfEarlierHandlerDisabled::No);
|
2016-03-18 02:22:37 +00:00
|
|
|
aCandidates.AppendElement(key);
|
|
|
|
}
|
|
|
|
// If unshiftedCharCodes doesn't have numeric but shiftedCharCode has it,
|
|
|
|
// this keyboard layout is AZERTY or similar layout, probably.
|
|
|
|
// In this case, Accel+[0-9] should be accessible without shift key.
|
|
|
|
// However, the priority should be lowest.
|
|
|
|
if (!HasASCIIDigit(aCandidates)) {
|
|
|
|
for (uint32_t i = 0; i < len; ++i) {
|
2016-05-12 08:57:21 +00:00
|
|
|
uint32_t ch = mAlternativeCharCodes[i].mShiftedCharCode;
|
2016-03-18 02:22:37 +00:00
|
|
|
if (ch >= '0' && ch <= '9') {
|
2023-08-09 04:47:06 +00:00
|
|
|
ShortcutKeyCandidate key(
|
|
|
|
ch, ShiftState::MatchExactly,
|
|
|
|
// Ctrl + `-` in the French keyboard layout should not match with
|
|
|
|
// Ctrl + `6` shortcut when it's already fully zoomed out.
|
|
|
|
SkipIfEarlierHandlerDisabled::Yes);
|
2016-03-18 02:22:37 +00:00
|
|
|
aCandidates.AppendElement(key);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
for (uint32_t i = 0; i < len; ++i) {
|
2016-05-12 08:57:21 +00:00
|
|
|
uint32_t ch = mAlternativeCharCodes[i].mShiftedCharCode;
|
2016-03-18 02:22:37 +00:00
|
|
|
if (!ch) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2016-03-19 11:57:11 +00:00
|
|
|
if (ch != pseudoCharCode) {
|
2023-08-09 04:47:06 +00:00
|
|
|
ShortcutKeyCandidate key(ch, ShiftState::MatchExactly,
|
|
|
|
SkipIfEarlierHandlerDisabled::No);
|
2016-03-18 02:22:37 +00:00
|
|
|
aCandidates.AppendElement(key);
|
|
|
|
}
|
|
|
|
|
|
|
|
// If the char is an alphabet, the shift key state should not be
|
|
|
|
// ignored. E.g., Ctrl+Shift+C should not execute Ctrl+C.
|
|
|
|
|
|
|
|
// And checking the charCode is same as unshiftedCharCode too.
|
|
|
|
// E.g., for Ctrl+Shift+(Plus of Numpad) should not run Ctrl+Plus.
|
2016-05-12 08:57:21 +00:00
|
|
|
uint32_t unshiftCh = mAlternativeCharCodes[i].mUnshiftedCharCode;
|
2016-03-18 02:22:37 +00:00
|
|
|
if (CharsCaseInsensitiveEqual(ch, unshiftCh)) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// On the Hebrew keyboard layout on Windows, the unshifted char is a
|
|
|
|
// localized character but the shifted char is a Latin alphabet,
|
|
|
|
// then, we should not execute without the shift state. See bug 433192.
|
|
|
|
if (IsCaseChangeableChar(ch)) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Setting the alternative charCode candidates for retry without shift
|
|
|
|
// key state only when the shift key is pressed.
|
2023-08-09 04:47:06 +00:00
|
|
|
ShortcutKeyCandidate key(ch, ShiftState::Ignorable,
|
|
|
|
SkipIfEarlierHandlerDisabled::No);
|
2016-03-18 02:22:37 +00:00
|
|
|
aCandidates.AppendElement(key);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Special case for "Space" key. With some keyboard layouts, "Space" with
|
|
|
|
// or without Shift key causes non-ASCII space. For such keyboard layouts,
|
|
|
|
// we should guarantee that the key press works as an ASCII white space key
|
2016-03-26 05:06:16 +00:00
|
|
|
// press. However, if the space key is assigned to a function key, it
|
|
|
|
// shouldn't work as a space key.
|
|
|
|
if (mKeyNameIndex == KEY_NAME_INDEX_USE_STRING &&
|
2016-05-13 07:06:18 +00:00
|
|
|
mCodeNameIndex == CODE_NAME_INDEX_Space && pseudoCharCode != ' ') {
|
2023-08-09 04:47:06 +00:00
|
|
|
ShortcutKeyCandidate spaceKey(' ', ShiftState::MatchExactly,
|
|
|
|
SkipIfEarlierHandlerDisabled::No);
|
2016-03-18 02:22:37 +00:00
|
|
|
aCandidates.AppendElement(spaceKey);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-05 23:09:40 +00:00
|
|
|
void WidgetKeyboardEvent::GetAccessKeyCandidates(
|
|
|
|
nsTArray<uint32_t>& aCandidates) const {
|
2016-03-18 02:22:37 +00:00
|
|
|
MOZ_ASSERT(aCandidates.IsEmpty(), "aCandidates must be empty");
|
|
|
|
|
|
|
|
// return the lower cased charCode candidates for access keys.
|
|
|
|
// the priority of the charCodes are:
|
|
|
|
// 0: charCode, 1: unshiftedCharCodes[0], 2: shiftedCharCodes[0]
|
|
|
|
// 3: unshiftedCharCodes[1], 4: shiftedCharCodes[1],...
|
2017-11-09 23:42:40 +00:00
|
|
|
uint32_t pseudoCharCode = PseudoCharCode();
|
|
|
|
if (pseudoCharCode) {
|
|
|
|
uint32_t ch = pseudoCharCode;
|
2016-03-18 02:22:37 +00:00
|
|
|
if (IS_IN_BMP(ch)) {
|
|
|
|
ch = ToLowerCase(static_cast<char16_t>(ch));
|
|
|
|
}
|
|
|
|
aCandidates.AppendElement(ch);
|
|
|
|
}
|
2016-05-12 08:57:21 +00:00
|
|
|
for (uint32_t i = 0; i < mAlternativeCharCodes.Length(); ++i) {
|
|
|
|
uint32_t ch[2] = {mAlternativeCharCodes[i].mUnshiftedCharCode,
|
|
|
|
mAlternativeCharCodes[i].mShiftedCharCode};
|
2016-03-18 02:22:37 +00:00
|
|
|
for (uint32_t j = 0; j < 2; ++j) {
|
|
|
|
if (!ch[j]) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (IS_IN_BMP(ch[j])) {
|
|
|
|
ch[j] = ToLowerCase(static_cast<char16_t>(ch[j]));
|
|
|
|
}
|
2017-11-09 23:42:40 +00:00
|
|
|
// Don't append the charcode that was already appended.
|
2016-03-18 02:22:37 +00:00
|
|
|
if (aCandidates.IndexOf(ch[j]) == aCandidates.NoIndex) {
|
|
|
|
aCandidates.AppendElement(ch[j]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
// Special case for "Space" key. With some keyboard layouts, "Space" with
|
|
|
|
// or without Shift key causes non-ASCII space. For such keyboard layouts,
|
|
|
|
// we should guarantee that the key press works as an ASCII white space key
|
2016-03-26 05:06:16 +00:00
|
|
|
// press. However, if the space key is assigned to a function key, it
|
|
|
|
// shouldn't work as a space key.
|
|
|
|
if (mKeyNameIndex == KEY_NAME_INDEX_USE_STRING &&
|
2017-11-09 23:42:40 +00:00
|
|
|
mCodeNameIndex == CODE_NAME_INDEX_Space && pseudoCharCode != ' ') {
|
2016-05-13 07:06:18 +00:00
|
|
|
aCandidates.AppendElement(' ');
|
2016-03-18 02:22:37 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-06 08:36:19 +00:00
|
|
|
// mask values for ui.key.chromeAccess and ui.key.contentAccess
|
|
|
|
#define NS_MODIFIER_SHIFT 1
|
|
|
|
#define NS_MODIFIER_CONTROL 2
|
|
|
|
#define NS_MODIFIER_ALT 4
|
|
|
|
#define NS_MODIFIER_META 8
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2017-07-06 08:36:19 +00:00
|
|
|
static Modifiers PrefFlagsToModifiers(int32_t aPrefFlags) {
|
|
|
|
Modifiers result = 0;
|
|
|
|
if (aPrefFlags & NS_MODIFIER_SHIFT) {
|
|
|
|
result |= MODIFIER_SHIFT;
|
|
|
|
}
|
|
|
|
if (aPrefFlags & NS_MODIFIER_CONTROL) {
|
|
|
|
result |= MODIFIER_CONTROL;
|
|
|
|
}
|
|
|
|
if (aPrefFlags & NS_MODIFIER_ALT) {
|
|
|
|
result |= MODIFIER_ALT;
|
|
|
|
}
|
|
|
|
if (aPrefFlags & NS_MODIFIER_META) {
|
|
|
|
result |= MODIFIER_META;
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool WidgetKeyboardEvent::ModifiersMatchWithAccessKey(
|
|
|
|
AccessKeyType aType) const {
|
|
|
|
if (!ModifiersForAccessKeyMatching()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return ModifiersForAccessKeyMatching() == AccessKeyModifiers(aType);
|
|
|
|
}
|
|
|
|
|
|
|
|
Modifiers WidgetKeyboardEvent::ModifiersForAccessKeyMatching() const {
|
Bug 1266437 - Drop "OS" modifier r=smaug,m_kato,karlt,Gijs
On Windows, Windows logo key was mapped to "OS" modifier, and on Linux,
it's same and the key is called "Super" and "Hyper". That conformed to the
older UI Events spec.
However, UI Events declares that they should be mapped to "Meta" now and Chrome
handles it as the spec in Windows and Linux. Therefore, we should align the
behavior to them.
Note that we've treated the legacy "Meta" modifier on Linux as DOM "Meta"
modifier state, and we'll keep this as-is because in Sun/Solaris keyboard
layout, they keys are mapped to the legacy "Meta".
Finally, the following check only `IsMeta()` but not `IsOS()`. I think that
they should've checked `IsOS()` too. Therefore, they will behave differently
in Windows and Linux.
* https://searchfox.org/mozilla-central/rev/9a4666e63199bd1bcfc9095f6efec3488c358458/dom/base/Element.cpp#3287-3288
* https://searchfox.org/mozilla-central/rev/9a4666e63199bd1bcfc9095f6efec3488c358458/dom/html/HTMLInputElement.cpp#3762-3764
* https://searchfox.org/mozilla-central/rev/9a4666e63199bd1bcfc9095f6efec3488c358458/dom/html/HTMLInputElement.cpp#3796-3806
* https://searchfox.org/mozilla-central/rev/9a4666e63199bd1bcfc9095f6efec3488c358458/dom/html/HTMLLabelElement.cpp#127-128
* https://searchfox.org/mozilla-central/rev/9a4666e63199bd1bcfc9095f6efec3488c358458/widget/gtk/nsGtkKeyUtils.cpp#1461-1462
Note that `KEY_NAME_INDEX_OS` will be removed in the patch for bug 1232918.
Differential Revision: https://phabricator.services.mozilla.com/D183480
2023-08-07 01:03:58 +00:00
|
|
|
static const Modifiers kModifierMask =
|
|
|
|
MODIFIER_SHIFT | MODIFIER_CONTROL | MODIFIER_ALT | MODIFIER_META;
|
2017-07-06 08:36:19 +00:00
|
|
|
return mModifiers & kModifierMask;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* static */
|
|
|
|
Modifiers WidgetKeyboardEvent::AccessKeyModifiers(AccessKeyType aType) {
|
2019-08-26 20:25:42 +00:00
|
|
|
switch (StaticPrefs::ui_key_generalAccessKey()) {
|
2017-07-06 08:36:19 +00:00
|
|
|
case -1:
|
|
|
|
break; // use the individual prefs
|
|
|
|
case NS_VK_SHIFT:
|
|
|
|
return MODIFIER_SHIFT;
|
|
|
|
case NS_VK_CONTROL:
|
|
|
|
return MODIFIER_CONTROL;
|
|
|
|
case NS_VK_ALT:
|
|
|
|
return MODIFIER_ALT;
|
|
|
|
case NS_VK_META:
|
2023-08-04 03:29:52 +00:00
|
|
|
case NS_VK_WIN:
|
Bug 1266437 - Drop "OS" modifier r=smaug,m_kato,karlt,Gijs
On Windows, Windows logo key was mapped to "OS" modifier, and on Linux,
it's same and the key is called "Super" and "Hyper". That conformed to the
older UI Events spec.
However, UI Events declares that they should be mapped to "Meta" now and Chrome
handles it as the spec in Windows and Linux. Therefore, we should align the
behavior to them.
Note that we've treated the legacy "Meta" modifier on Linux as DOM "Meta"
modifier state, and we'll keep this as-is because in Sun/Solaris keyboard
layout, they keys are mapped to the legacy "Meta".
Finally, the following check only `IsMeta()` but not `IsOS()`. I think that
they should've checked `IsOS()` too. Therefore, they will behave differently
in Windows and Linux.
* https://searchfox.org/mozilla-central/rev/9a4666e63199bd1bcfc9095f6efec3488c358458/dom/base/Element.cpp#3287-3288
* https://searchfox.org/mozilla-central/rev/9a4666e63199bd1bcfc9095f6efec3488c358458/dom/html/HTMLInputElement.cpp#3762-3764
* https://searchfox.org/mozilla-central/rev/9a4666e63199bd1bcfc9095f6efec3488c358458/dom/html/HTMLInputElement.cpp#3796-3806
* https://searchfox.org/mozilla-central/rev/9a4666e63199bd1bcfc9095f6efec3488c358458/dom/html/HTMLLabelElement.cpp#127-128
* https://searchfox.org/mozilla-central/rev/9a4666e63199bd1bcfc9095f6efec3488c358458/widget/gtk/nsGtkKeyUtils.cpp#1461-1462
Note that `KEY_NAME_INDEX_OS` will be removed in the patch for bug 1232918.
Differential Revision: https://phabricator.services.mozilla.com/D183480
2023-08-07 01:03:58 +00:00
|
|
|
return MODIFIER_META;
|
2017-07-06 08:36:19 +00:00
|
|
|
default:
|
|
|
|
return MODIFIER_NONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (aType) {
|
|
|
|
case AccessKeyType::eChrome:
|
2019-08-26 20:25:42 +00:00
|
|
|
return PrefFlagsToModifiers(StaticPrefs::ui_key_chromeAccess());
|
2017-07-06 08:36:19 +00:00
|
|
|
case AccessKeyType::eContent:
|
2019-08-26 20:25:42 +00:00
|
|
|
return PrefFlagsToModifiers(StaticPrefs::ui_key_contentAccess());
|
2017-07-06 08:36:19 +00:00
|
|
|
default:
|
|
|
|
return MODIFIER_NONE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-02-25 22:13:48 +00:00
|
|
|
/* static */
|
|
|
|
void WidgetKeyboardEvent::Shutdown() {
|
2015-02-19 06:50:19 +00:00
|
|
|
delete sKeyNameIndexHashtable;
|
|
|
|
sKeyNameIndexHashtable = nullptr;
|
|
|
|
delete sCodeNameIndexHashtable;
|
|
|
|
sCodeNameIndexHashtable = nullptr;
|
2019-04-30 04:24:26 +00:00
|
|
|
// Although sCommandHashtable is not a member of WidgetKeyboardEvent, but
|
|
|
|
// let's delete it here since we need to do it at same time.
|
|
|
|
delete sCommandHashtable;
|
|
|
|
sCommandHashtable = nullptr;
|
2015-02-19 06:50:19 +00:00
|
|
|
}
|
|
|
|
|
2019-02-25 22:13:48 +00:00
|
|
|
/* static */
|
|
|
|
void WidgetKeyboardEvent::GetDOMKeyName(KeyNameIndex aKeyNameIndex,
|
|
|
|
nsAString& aKeyName) {
|
2014-01-08 16:45:30 +00:00
|
|
|
if (aKeyNameIndex >= KEY_NAME_INDEX_USE_STRING) {
|
|
|
|
aKeyName.Truncate();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
Bug 1922838 - Replace ArrayLength, ArrayEnd and MOZ_ARRAY_LENGTH by standard alternative r=glandium,necko-reviewers,jgilbert,application-update-reviewers,media-playback-reviewers,credential-management-reviewers,anti-tracking-reviewers,places-reviewers,profiler-reviewers,win-reviewers,dom-storage-reviewers,bytesized,janv,dimi,daisuke,karlt,gstoll,canaltinova,timhuang
Namely std::size, std::end and std::size. This drops C support for
MOZ_ARRAY_LENGTH but it wasn't used anyway.
Differential Revision: https://phabricator.services.mozilla.com/D224611
2024-10-28 08:21:19 +00:00
|
|
|
MOZ_RELEASE_ASSERT(static_cast<size_t>(aKeyNameIndex) < std::size(kKeyNames),
|
|
|
|
"Illegal key enumeration value");
|
2015-02-19 06:50:19 +00:00
|
|
|
aKeyName = kKeyNames[aKeyNameIndex];
|
2014-01-08 16:45:30 +00:00
|
|
|
}
|
|
|
|
|
2019-02-25 22:13:48 +00:00
|
|
|
/* static */
|
|
|
|
void WidgetKeyboardEvent::GetDOMCodeName(CodeNameIndex aCodeNameIndex,
|
|
|
|
nsAString& aCodeName) {
|
2014-05-25 02:08:58 +00:00
|
|
|
if (aCodeNameIndex >= CODE_NAME_INDEX_USE_STRING) {
|
|
|
|
aCodeName.Truncate();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
MOZ_RELEASE_ASSERT(
|
Bug 1922838 - Replace ArrayLength, ArrayEnd and MOZ_ARRAY_LENGTH by standard alternative r=glandium,necko-reviewers,jgilbert,application-update-reviewers,media-playback-reviewers,credential-management-reviewers,anti-tracking-reviewers,places-reviewers,profiler-reviewers,win-reviewers,dom-storage-reviewers,bytesized,janv,dimi,daisuke,karlt,gstoll,canaltinova,timhuang
Namely std::size, std::end and std::size. This drops C support for
MOZ_ARRAY_LENGTH but it wasn't used anyway.
Differential Revision: https://phabricator.services.mozilla.com/D224611
2024-10-28 08:21:19 +00:00
|
|
|
static_cast<size_t>(aCodeNameIndex) < std::size(kCodeNames),
|
2014-05-25 02:08:58 +00:00
|
|
|
"Illegal physical code enumeration value");
|
2022-10-14 21:32:17 +00:00
|
|
|
|
|
|
|
// Generate some continuous runs of codes, rather than looking them up.
|
|
|
|
if (aCodeNameIndex >= CODE_NAME_INDEX_KeyA &&
|
|
|
|
aCodeNameIndex <= CODE_NAME_INDEX_KeyZ) {
|
|
|
|
uint32_t index = aCodeNameIndex - CODE_NAME_INDEX_KeyA;
|
|
|
|
aCodeName.AssignLiteral(u"Key");
|
|
|
|
aCodeName.Append(u'A' + index);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (aCodeNameIndex >= CODE_NAME_INDEX_Digit0 &&
|
|
|
|
aCodeNameIndex <= CODE_NAME_INDEX_Digit9) {
|
|
|
|
uint32_t index = aCodeNameIndex - CODE_NAME_INDEX_Digit0;
|
|
|
|
aCodeName.AssignLiteral(u"Digit");
|
|
|
|
aCodeName.AppendInt(index);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (aCodeNameIndex >= CODE_NAME_INDEX_Numpad0 &&
|
|
|
|
aCodeNameIndex <= CODE_NAME_INDEX_Numpad9) {
|
|
|
|
uint32_t index = aCodeNameIndex - CODE_NAME_INDEX_Numpad0;
|
|
|
|
aCodeName.AssignLiteral(u"Numpad");
|
|
|
|
aCodeName.AppendInt(index);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (aCodeNameIndex >= CODE_NAME_INDEX_F1 &&
|
|
|
|
aCodeNameIndex <= CODE_NAME_INDEX_F24) {
|
|
|
|
uint32_t index = aCodeNameIndex - CODE_NAME_INDEX_F1;
|
|
|
|
aCodeName.Assign(u'F');
|
|
|
|
aCodeName.AppendInt(index + 1);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-05-25 02:08:58 +00:00
|
|
|
aCodeName = kCodeNames[aCodeNameIndex];
|
|
|
|
}
|
|
|
|
|
2019-02-25 22:13:48 +00:00
|
|
|
/* static */
|
|
|
|
KeyNameIndex WidgetKeyboardEvent::GetKeyNameIndex(const nsAString& aKeyValue) {
|
2015-02-19 06:50:19 +00:00
|
|
|
if (!sKeyNameIndexHashtable) {
|
Bug 1922838 - Replace ArrayLength, ArrayEnd and MOZ_ARRAY_LENGTH by standard alternative r=glandium,necko-reviewers,jgilbert,application-update-reviewers,media-playback-reviewers,credential-management-reviewers,anti-tracking-reviewers,places-reviewers,profiler-reviewers,win-reviewers,dom-storage-reviewers,bytesized,janv,dimi,daisuke,karlt,gstoll,canaltinova,timhuang
Namely std::size, std::end and std::size. This drops C support for
MOZ_ARRAY_LENGTH but it wasn't used anyway.
Differential Revision: https://phabricator.services.mozilla.com/D224611
2024-10-28 08:21:19 +00:00
|
|
|
sKeyNameIndexHashtable = new KeyNameIndexHashtable(std::size(kKeyNames));
|
|
|
|
for (size_t i = 0; i < std::size(kKeyNames); i++) {
|
2021-02-26 09:11:46 +00:00
|
|
|
sKeyNameIndexHashtable->InsertOrUpdate(nsDependentString(kKeyNames[i]),
|
|
|
|
static_cast<KeyNameIndex>(i));
|
2015-02-19 06:50:19 +00:00
|
|
|
}
|
|
|
|
}
|
2021-02-26 09:22:53 +00:00
|
|
|
return sKeyNameIndexHashtable->MaybeGet(aKeyValue).valueOr(
|
|
|
|
KEY_NAME_INDEX_USE_STRING);
|
2015-02-19 06:50:19 +00:00
|
|
|
}
|
|
|
|
|
2019-02-25 22:13:48 +00:00
|
|
|
/* static */
|
|
|
|
CodeNameIndex WidgetKeyboardEvent::GetCodeNameIndex(
|
2015-02-19 06:50:19 +00:00
|
|
|
const nsAString& aCodeValue) {
|
|
|
|
if (!sCodeNameIndexHashtable) {
|
Bug 1922838 - Replace ArrayLength, ArrayEnd and MOZ_ARRAY_LENGTH by standard alternative r=glandium,necko-reviewers,jgilbert,application-update-reviewers,media-playback-reviewers,credential-management-reviewers,anti-tracking-reviewers,places-reviewers,profiler-reviewers,win-reviewers,dom-storage-reviewers,bytesized,janv,dimi,daisuke,karlt,gstoll,canaltinova,timhuang
Namely std::size, std::end and std::size. This drops C support for
MOZ_ARRAY_LENGTH but it wasn't used anyway.
Differential Revision: https://phabricator.services.mozilla.com/D224611
2024-10-28 08:21:19 +00:00
|
|
|
sCodeNameIndexHashtable = new CodeNameIndexHashtable(std::size(kCodeNames));
|
|
|
|
for (size_t i = 0; i < std::size(kCodeNames); i++) {
|
2021-02-26 09:11:46 +00:00
|
|
|
sCodeNameIndexHashtable->InsertOrUpdate(nsDependentString(kCodeNames[i]),
|
|
|
|
static_cast<CodeNameIndex>(i));
|
2015-02-19 06:50:19 +00:00
|
|
|
}
|
|
|
|
}
|
2021-02-26 09:22:53 +00:00
|
|
|
return sCodeNameIndexHashtable->MaybeGet(aCodeValue)
|
|
|
|
.valueOr(CODE_NAME_INDEX_USE_STRING);
|
2015-02-19 06:50:19 +00:00
|
|
|
}
|
|
|
|
|
2019-02-25 22:13:48 +00:00
|
|
|
/* static */
|
|
|
|
uint32_t WidgetKeyboardEvent::GetFallbackKeyCodeOfPunctuationKey(
|
Bug 1036008 - Use alternative ASCII capable keyboard layout information to decide keyCode even if the key produces an ASCII punctuation character r=smaug
Gecko decides keyCode from an ASCII character which is produced by the key
by itself or with Shift on active keyboard layout or alternative ASCII capable
keyboard layout if active keyboard layout isn't ASCII capable. However, we've
ignored alternative ASCII capable keyboard layout's character if both the
key itself and with Shift don't produce ASCII alphabet nor ASCII numeral,
i.e., ASCII punctuation characters are not used in alternative ASCII capable
keyboard layout because of avoiding mapping a keyCode value to 2 or more keys.
However, setting 0 to keyCode value makes Firefox unusable with some web
applications which are aware of neither KeyboardEvent.key nor
KeyboardEvent.code. So, even if we map same keyCode value to a key, we should
avoid setting keyCode value to 0 as far as possible.
This patch's approach is, we behave same keyCode value as the alternative ASCII
capable keyCode is selected when computed keyCode value of active keyboard
layout is 0. This means that we will make some language users whose keyboard
layout for their language is not ASCII capable can use global web services
which support US keyboard layout of Firefox since the new keyCode values
are mostly computed with US layout on Windows or actual alternative ASCII
capable keyboard layout on macOS and Linux. In other words, we cannot improve
compatibility with web applications which don't support Firefox by this patch
since our keyCode values are really different from Chrome's. So, unfortunately,
if we'd use exactly same keyCode computation as Chromium, we'd break
compatibility with existing web applications which are aware of Firefox since
it's necessary to check UA name or something before using keyCode values.
Note that the most important difference between Windows and the others is,
such keyCode value is computed with alternative ASCII capable keyboard
layout on macOS and Linux but only on Windows, it's computed with OEM virtual
keycode. This means that only on Windows, the keyCode value may be different
from actual alternative ASCII capable keyboard layout's keyCode.
MozReview-Commit-ID: As289r9wp6i
--HG--
extra : rebase_source : 66181403dbe8ca8dab893edc8f4eec1991d544d0
2018-02-16 06:54:07 +00:00
|
|
|
CodeNameIndex aCodeNameIndex) {
|
|
|
|
switch (aCodeNameIndex) {
|
|
|
|
case CODE_NAME_INDEX_Semicolon: // VK_OEM_1 on Windows
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_SEMICOLON;
|
Bug 1036008 - Use alternative ASCII capable keyboard layout information to decide keyCode even if the key produces an ASCII punctuation character r=smaug
Gecko decides keyCode from an ASCII character which is produced by the key
by itself or with Shift on active keyboard layout or alternative ASCII capable
keyboard layout if active keyboard layout isn't ASCII capable. However, we've
ignored alternative ASCII capable keyboard layout's character if both the
key itself and with Shift don't produce ASCII alphabet nor ASCII numeral,
i.e., ASCII punctuation characters are not used in alternative ASCII capable
keyboard layout because of avoiding mapping a keyCode value to 2 or more keys.
However, setting 0 to keyCode value makes Firefox unusable with some web
applications which are aware of neither KeyboardEvent.key nor
KeyboardEvent.code. So, even if we map same keyCode value to a key, we should
avoid setting keyCode value to 0 as far as possible.
This patch's approach is, we behave same keyCode value as the alternative ASCII
capable keyCode is selected when computed keyCode value of active keyboard
layout is 0. This means that we will make some language users whose keyboard
layout for their language is not ASCII capable can use global web services
which support US keyboard layout of Firefox since the new keyCode values
are mostly computed with US layout on Windows or actual alternative ASCII
capable keyboard layout on macOS and Linux. In other words, we cannot improve
compatibility with web applications which don't support Firefox by this patch
since our keyCode values are really different from Chrome's. So, unfortunately,
if we'd use exactly same keyCode computation as Chromium, we'd break
compatibility with existing web applications which are aware of Firefox since
it's necessary to check UA name or something before using keyCode values.
Note that the most important difference between Windows and the others is,
such keyCode value is computed with alternative ASCII capable keyboard
layout on macOS and Linux but only on Windows, it's computed with OEM virtual
keycode. This means that only on Windows, the keyCode value may be different
from actual alternative ASCII capable keyboard layout's keyCode.
MozReview-Commit-ID: As289r9wp6i
--HG--
extra : rebase_source : 66181403dbe8ca8dab893edc8f4eec1991d544d0
2018-02-16 06:54:07 +00:00
|
|
|
case CODE_NAME_INDEX_Equal: // VK_OEM_PLUS on Windows
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_EQUALS;
|
Bug 1036008 - Use alternative ASCII capable keyboard layout information to decide keyCode even if the key produces an ASCII punctuation character r=smaug
Gecko decides keyCode from an ASCII character which is produced by the key
by itself or with Shift on active keyboard layout or alternative ASCII capable
keyboard layout if active keyboard layout isn't ASCII capable. However, we've
ignored alternative ASCII capable keyboard layout's character if both the
key itself and with Shift don't produce ASCII alphabet nor ASCII numeral,
i.e., ASCII punctuation characters are not used in alternative ASCII capable
keyboard layout because of avoiding mapping a keyCode value to 2 or more keys.
However, setting 0 to keyCode value makes Firefox unusable with some web
applications which are aware of neither KeyboardEvent.key nor
KeyboardEvent.code. So, even if we map same keyCode value to a key, we should
avoid setting keyCode value to 0 as far as possible.
This patch's approach is, we behave same keyCode value as the alternative ASCII
capable keyCode is selected when computed keyCode value of active keyboard
layout is 0. This means that we will make some language users whose keyboard
layout for their language is not ASCII capable can use global web services
which support US keyboard layout of Firefox since the new keyCode values
are mostly computed with US layout on Windows or actual alternative ASCII
capable keyboard layout on macOS and Linux. In other words, we cannot improve
compatibility with web applications which don't support Firefox by this patch
since our keyCode values are really different from Chrome's. So, unfortunately,
if we'd use exactly same keyCode computation as Chromium, we'd break
compatibility with existing web applications which are aware of Firefox since
it's necessary to check UA name or something before using keyCode values.
Note that the most important difference between Windows and the others is,
such keyCode value is computed with alternative ASCII capable keyboard
layout on macOS and Linux but only on Windows, it's computed with OEM virtual
keycode. This means that only on Windows, the keyCode value may be different
from actual alternative ASCII capable keyboard layout's keyCode.
MozReview-Commit-ID: As289r9wp6i
--HG--
extra : rebase_source : 66181403dbe8ca8dab893edc8f4eec1991d544d0
2018-02-16 06:54:07 +00:00
|
|
|
case CODE_NAME_INDEX_Comma: // VK_OEM_COMMA on Windows
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_COMMA;
|
Bug 1036008 - Use alternative ASCII capable keyboard layout information to decide keyCode even if the key produces an ASCII punctuation character r=smaug
Gecko decides keyCode from an ASCII character which is produced by the key
by itself or with Shift on active keyboard layout or alternative ASCII capable
keyboard layout if active keyboard layout isn't ASCII capable. However, we've
ignored alternative ASCII capable keyboard layout's character if both the
key itself and with Shift don't produce ASCII alphabet nor ASCII numeral,
i.e., ASCII punctuation characters are not used in alternative ASCII capable
keyboard layout because of avoiding mapping a keyCode value to 2 or more keys.
However, setting 0 to keyCode value makes Firefox unusable with some web
applications which are aware of neither KeyboardEvent.key nor
KeyboardEvent.code. So, even if we map same keyCode value to a key, we should
avoid setting keyCode value to 0 as far as possible.
This patch's approach is, we behave same keyCode value as the alternative ASCII
capable keyCode is selected when computed keyCode value of active keyboard
layout is 0. This means that we will make some language users whose keyboard
layout for their language is not ASCII capable can use global web services
which support US keyboard layout of Firefox since the new keyCode values
are mostly computed with US layout on Windows or actual alternative ASCII
capable keyboard layout on macOS and Linux. In other words, we cannot improve
compatibility with web applications which don't support Firefox by this patch
since our keyCode values are really different from Chrome's. So, unfortunately,
if we'd use exactly same keyCode computation as Chromium, we'd break
compatibility with existing web applications which are aware of Firefox since
it's necessary to check UA name or something before using keyCode values.
Note that the most important difference between Windows and the others is,
such keyCode value is computed with alternative ASCII capable keyboard
layout on macOS and Linux but only on Windows, it's computed with OEM virtual
keycode. This means that only on Windows, the keyCode value may be different
from actual alternative ASCII capable keyboard layout's keyCode.
MozReview-Commit-ID: As289r9wp6i
--HG--
extra : rebase_source : 66181403dbe8ca8dab893edc8f4eec1991d544d0
2018-02-16 06:54:07 +00:00
|
|
|
case CODE_NAME_INDEX_Minus: // VK_OEM_MINUS on Windows
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_HYPHEN_MINUS;
|
Bug 1036008 - Use alternative ASCII capable keyboard layout information to decide keyCode even if the key produces an ASCII punctuation character r=smaug
Gecko decides keyCode from an ASCII character which is produced by the key
by itself or with Shift on active keyboard layout or alternative ASCII capable
keyboard layout if active keyboard layout isn't ASCII capable. However, we've
ignored alternative ASCII capable keyboard layout's character if both the
key itself and with Shift don't produce ASCII alphabet nor ASCII numeral,
i.e., ASCII punctuation characters are not used in alternative ASCII capable
keyboard layout because of avoiding mapping a keyCode value to 2 or more keys.
However, setting 0 to keyCode value makes Firefox unusable with some web
applications which are aware of neither KeyboardEvent.key nor
KeyboardEvent.code. So, even if we map same keyCode value to a key, we should
avoid setting keyCode value to 0 as far as possible.
This patch's approach is, we behave same keyCode value as the alternative ASCII
capable keyCode is selected when computed keyCode value of active keyboard
layout is 0. This means that we will make some language users whose keyboard
layout for their language is not ASCII capable can use global web services
which support US keyboard layout of Firefox since the new keyCode values
are mostly computed with US layout on Windows or actual alternative ASCII
capable keyboard layout on macOS and Linux. In other words, we cannot improve
compatibility with web applications which don't support Firefox by this patch
since our keyCode values are really different from Chrome's. So, unfortunately,
if we'd use exactly same keyCode computation as Chromium, we'd break
compatibility with existing web applications which are aware of Firefox since
it's necessary to check UA name or something before using keyCode values.
Note that the most important difference between Windows and the others is,
such keyCode value is computed with alternative ASCII capable keyboard
layout on macOS and Linux but only on Windows, it's computed with OEM virtual
keycode. This means that only on Windows, the keyCode value may be different
from actual alternative ASCII capable keyboard layout's keyCode.
MozReview-Commit-ID: As289r9wp6i
--HG--
extra : rebase_source : 66181403dbe8ca8dab893edc8f4eec1991d544d0
2018-02-16 06:54:07 +00:00
|
|
|
case CODE_NAME_INDEX_Period: // VK_OEM_PERIOD on Windows
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_PERIOD;
|
Bug 1036008 - Use alternative ASCII capable keyboard layout information to decide keyCode even if the key produces an ASCII punctuation character r=smaug
Gecko decides keyCode from an ASCII character which is produced by the key
by itself or with Shift on active keyboard layout or alternative ASCII capable
keyboard layout if active keyboard layout isn't ASCII capable. However, we've
ignored alternative ASCII capable keyboard layout's character if both the
key itself and with Shift don't produce ASCII alphabet nor ASCII numeral,
i.e., ASCII punctuation characters are not used in alternative ASCII capable
keyboard layout because of avoiding mapping a keyCode value to 2 or more keys.
However, setting 0 to keyCode value makes Firefox unusable with some web
applications which are aware of neither KeyboardEvent.key nor
KeyboardEvent.code. So, even if we map same keyCode value to a key, we should
avoid setting keyCode value to 0 as far as possible.
This patch's approach is, we behave same keyCode value as the alternative ASCII
capable keyCode is selected when computed keyCode value of active keyboard
layout is 0. This means that we will make some language users whose keyboard
layout for their language is not ASCII capable can use global web services
which support US keyboard layout of Firefox since the new keyCode values
are mostly computed with US layout on Windows or actual alternative ASCII
capable keyboard layout on macOS and Linux. In other words, we cannot improve
compatibility with web applications which don't support Firefox by this patch
since our keyCode values are really different from Chrome's. So, unfortunately,
if we'd use exactly same keyCode computation as Chromium, we'd break
compatibility with existing web applications which are aware of Firefox since
it's necessary to check UA name or something before using keyCode values.
Note that the most important difference between Windows and the others is,
such keyCode value is computed with alternative ASCII capable keyboard
layout on macOS and Linux but only on Windows, it's computed with OEM virtual
keycode. This means that only on Windows, the keyCode value may be different
from actual alternative ASCII capable keyboard layout's keyCode.
MozReview-Commit-ID: As289r9wp6i
--HG--
extra : rebase_source : 66181403dbe8ca8dab893edc8f4eec1991d544d0
2018-02-16 06:54:07 +00:00
|
|
|
case CODE_NAME_INDEX_Slash: // VK_OEM_2 on Windows
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_SLASH;
|
Bug 1036008 - Use alternative ASCII capable keyboard layout information to decide keyCode even if the key produces an ASCII punctuation character r=smaug
Gecko decides keyCode from an ASCII character which is produced by the key
by itself or with Shift on active keyboard layout or alternative ASCII capable
keyboard layout if active keyboard layout isn't ASCII capable. However, we've
ignored alternative ASCII capable keyboard layout's character if both the
key itself and with Shift don't produce ASCII alphabet nor ASCII numeral,
i.e., ASCII punctuation characters are not used in alternative ASCII capable
keyboard layout because of avoiding mapping a keyCode value to 2 or more keys.
However, setting 0 to keyCode value makes Firefox unusable with some web
applications which are aware of neither KeyboardEvent.key nor
KeyboardEvent.code. So, even if we map same keyCode value to a key, we should
avoid setting keyCode value to 0 as far as possible.
This patch's approach is, we behave same keyCode value as the alternative ASCII
capable keyCode is selected when computed keyCode value of active keyboard
layout is 0. This means that we will make some language users whose keyboard
layout for their language is not ASCII capable can use global web services
which support US keyboard layout of Firefox since the new keyCode values
are mostly computed with US layout on Windows or actual alternative ASCII
capable keyboard layout on macOS and Linux. In other words, we cannot improve
compatibility with web applications which don't support Firefox by this patch
since our keyCode values are really different from Chrome's. So, unfortunately,
if we'd use exactly same keyCode computation as Chromium, we'd break
compatibility with existing web applications which are aware of Firefox since
it's necessary to check UA name or something before using keyCode values.
Note that the most important difference between Windows and the others is,
such keyCode value is computed with alternative ASCII capable keyboard
layout on macOS and Linux but only on Windows, it's computed with OEM virtual
keycode. This means that only on Windows, the keyCode value may be different
from actual alternative ASCII capable keyboard layout's keyCode.
MozReview-Commit-ID: As289r9wp6i
--HG--
extra : rebase_source : 66181403dbe8ca8dab893edc8f4eec1991d544d0
2018-02-16 06:54:07 +00:00
|
|
|
case CODE_NAME_INDEX_Backquote: // VK_OEM_3 on Windows
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_BACK_QUOTE;
|
Bug 1036008 - Use alternative ASCII capable keyboard layout information to decide keyCode even if the key produces an ASCII punctuation character r=smaug
Gecko decides keyCode from an ASCII character which is produced by the key
by itself or with Shift on active keyboard layout or alternative ASCII capable
keyboard layout if active keyboard layout isn't ASCII capable. However, we've
ignored alternative ASCII capable keyboard layout's character if both the
key itself and with Shift don't produce ASCII alphabet nor ASCII numeral,
i.e., ASCII punctuation characters are not used in alternative ASCII capable
keyboard layout because of avoiding mapping a keyCode value to 2 or more keys.
However, setting 0 to keyCode value makes Firefox unusable with some web
applications which are aware of neither KeyboardEvent.key nor
KeyboardEvent.code. So, even if we map same keyCode value to a key, we should
avoid setting keyCode value to 0 as far as possible.
This patch's approach is, we behave same keyCode value as the alternative ASCII
capable keyCode is selected when computed keyCode value of active keyboard
layout is 0. This means that we will make some language users whose keyboard
layout for their language is not ASCII capable can use global web services
which support US keyboard layout of Firefox since the new keyCode values
are mostly computed with US layout on Windows or actual alternative ASCII
capable keyboard layout on macOS and Linux. In other words, we cannot improve
compatibility with web applications which don't support Firefox by this patch
since our keyCode values are really different from Chrome's. So, unfortunately,
if we'd use exactly same keyCode computation as Chromium, we'd break
compatibility with existing web applications which are aware of Firefox since
it's necessary to check UA name or something before using keyCode values.
Note that the most important difference between Windows and the others is,
such keyCode value is computed with alternative ASCII capable keyboard
layout on macOS and Linux but only on Windows, it's computed with OEM virtual
keycode. This means that only on Windows, the keyCode value may be different
from actual alternative ASCII capable keyboard layout's keyCode.
MozReview-Commit-ID: As289r9wp6i
--HG--
extra : rebase_source : 66181403dbe8ca8dab893edc8f4eec1991d544d0
2018-02-16 06:54:07 +00:00
|
|
|
case CODE_NAME_INDEX_BracketLeft: // VK_OEM_4 on Windows
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_OPEN_BRACKET;
|
Bug 1036008 - Use alternative ASCII capable keyboard layout information to decide keyCode even if the key produces an ASCII punctuation character r=smaug
Gecko decides keyCode from an ASCII character which is produced by the key
by itself or with Shift on active keyboard layout or alternative ASCII capable
keyboard layout if active keyboard layout isn't ASCII capable. However, we've
ignored alternative ASCII capable keyboard layout's character if both the
key itself and with Shift don't produce ASCII alphabet nor ASCII numeral,
i.e., ASCII punctuation characters are not used in alternative ASCII capable
keyboard layout because of avoiding mapping a keyCode value to 2 or more keys.
However, setting 0 to keyCode value makes Firefox unusable with some web
applications which are aware of neither KeyboardEvent.key nor
KeyboardEvent.code. So, even if we map same keyCode value to a key, we should
avoid setting keyCode value to 0 as far as possible.
This patch's approach is, we behave same keyCode value as the alternative ASCII
capable keyCode is selected when computed keyCode value of active keyboard
layout is 0. This means that we will make some language users whose keyboard
layout for their language is not ASCII capable can use global web services
which support US keyboard layout of Firefox since the new keyCode values
are mostly computed with US layout on Windows or actual alternative ASCII
capable keyboard layout on macOS and Linux. In other words, we cannot improve
compatibility with web applications which don't support Firefox by this patch
since our keyCode values are really different from Chrome's. So, unfortunately,
if we'd use exactly same keyCode computation as Chromium, we'd break
compatibility with existing web applications which are aware of Firefox since
it's necessary to check UA name or something before using keyCode values.
Note that the most important difference between Windows and the others is,
such keyCode value is computed with alternative ASCII capable keyboard
layout on macOS and Linux but only on Windows, it's computed with OEM virtual
keycode. This means that only on Windows, the keyCode value may be different
from actual alternative ASCII capable keyboard layout's keyCode.
MozReview-Commit-ID: As289r9wp6i
--HG--
extra : rebase_source : 66181403dbe8ca8dab893edc8f4eec1991d544d0
2018-02-16 06:54:07 +00:00
|
|
|
case CODE_NAME_INDEX_Backslash: // VK_OEM_5 on Windows
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_BACK_SLASH;
|
Bug 1036008 - Use alternative ASCII capable keyboard layout information to decide keyCode even if the key produces an ASCII punctuation character r=smaug
Gecko decides keyCode from an ASCII character which is produced by the key
by itself or with Shift on active keyboard layout or alternative ASCII capable
keyboard layout if active keyboard layout isn't ASCII capable. However, we've
ignored alternative ASCII capable keyboard layout's character if both the
key itself and with Shift don't produce ASCII alphabet nor ASCII numeral,
i.e., ASCII punctuation characters are not used in alternative ASCII capable
keyboard layout because of avoiding mapping a keyCode value to 2 or more keys.
However, setting 0 to keyCode value makes Firefox unusable with some web
applications which are aware of neither KeyboardEvent.key nor
KeyboardEvent.code. So, even if we map same keyCode value to a key, we should
avoid setting keyCode value to 0 as far as possible.
This patch's approach is, we behave same keyCode value as the alternative ASCII
capable keyCode is selected when computed keyCode value of active keyboard
layout is 0. This means that we will make some language users whose keyboard
layout for their language is not ASCII capable can use global web services
which support US keyboard layout of Firefox since the new keyCode values
are mostly computed with US layout on Windows or actual alternative ASCII
capable keyboard layout on macOS and Linux. In other words, we cannot improve
compatibility with web applications which don't support Firefox by this patch
since our keyCode values are really different from Chrome's. So, unfortunately,
if we'd use exactly same keyCode computation as Chromium, we'd break
compatibility with existing web applications which are aware of Firefox since
it's necessary to check UA name or something before using keyCode values.
Note that the most important difference between Windows and the others is,
such keyCode value is computed with alternative ASCII capable keyboard
layout on macOS and Linux but only on Windows, it's computed with OEM virtual
keycode. This means that only on Windows, the keyCode value may be different
from actual alternative ASCII capable keyboard layout's keyCode.
MozReview-Commit-ID: As289r9wp6i
--HG--
extra : rebase_source : 66181403dbe8ca8dab893edc8f4eec1991d544d0
2018-02-16 06:54:07 +00:00
|
|
|
case CODE_NAME_INDEX_BracketRight: // VK_OEM_6 on Windows
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_CLOSE_BRACKET;
|
Bug 1036008 - Use alternative ASCII capable keyboard layout information to decide keyCode even if the key produces an ASCII punctuation character r=smaug
Gecko decides keyCode from an ASCII character which is produced by the key
by itself or with Shift on active keyboard layout or alternative ASCII capable
keyboard layout if active keyboard layout isn't ASCII capable. However, we've
ignored alternative ASCII capable keyboard layout's character if both the
key itself and with Shift don't produce ASCII alphabet nor ASCII numeral,
i.e., ASCII punctuation characters are not used in alternative ASCII capable
keyboard layout because of avoiding mapping a keyCode value to 2 or more keys.
However, setting 0 to keyCode value makes Firefox unusable with some web
applications which are aware of neither KeyboardEvent.key nor
KeyboardEvent.code. So, even if we map same keyCode value to a key, we should
avoid setting keyCode value to 0 as far as possible.
This patch's approach is, we behave same keyCode value as the alternative ASCII
capable keyCode is selected when computed keyCode value of active keyboard
layout is 0. This means that we will make some language users whose keyboard
layout for their language is not ASCII capable can use global web services
which support US keyboard layout of Firefox since the new keyCode values
are mostly computed with US layout on Windows or actual alternative ASCII
capable keyboard layout on macOS and Linux. In other words, we cannot improve
compatibility with web applications which don't support Firefox by this patch
since our keyCode values are really different from Chrome's. So, unfortunately,
if we'd use exactly same keyCode computation as Chromium, we'd break
compatibility with existing web applications which are aware of Firefox since
it's necessary to check UA name or something before using keyCode values.
Note that the most important difference between Windows and the others is,
such keyCode value is computed with alternative ASCII capable keyboard
layout on macOS and Linux but only on Windows, it's computed with OEM virtual
keycode. This means that only on Windows, the keyCode value may be different
from actual alternative ASCII capable keyboard layout's keyCode.
MozReview-Commit-ID: As289r9wp6i
--HG--
extra : rebase_source : 66181403dbe8ca8dab893edc8f4eec1991d544d0
2018-02-16 06:54:07 +00:00
|
|
|
case CODE_NAME_INDEX_Quote: // VK_OEM_7 on Windows
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_QUOTE;
|
Bug 1036008 - Use alternative ASCII capable keyboard layout information to decide keyCode even if the key produces an ASCII punctuation character r=smaug
Gecko decides keyCode from an ASCII character which is produced by the key
by itself or with Shift on active keyboard layout or alternative ASCII capable
keyboard layout if active keyboard layout isn't ASCII capable. However, we've
ignored alternative ASCII capable keyboard layout's character if both the
key itself and with Shift don't produce ASCII alphabet nor ASCII numeral,
i.e., ASCII punctuation characters are not used in alternative ASCII capable
keyboard layout because of avoiding mapping a keyCode value to 2 or more keys.
However, setting 0 to keyCode value makes Firefox unusable with some web
applications which are aware of neither KeyboardEvent.key nor
KeyboardEvent.code. So, even if we map same keyCode value to a key, we should
avoid setting keyCode value to 0 as far as possible.
This patch's approach is, we behave same keyCode value as the alternative ASCII
capable keyCode is selected when computed keyCode value of active keyboard
layout is 0. This means that we will make some language users whose keyboard
layout for their language is not ASCII capable can use global web services
which support US keyboard layout of Firefox since the new keyCode values
are mostly computed with US layout on Windows or actual alternative ASCII
capable keyboard layout on macOS and Linux. In other words, we cannot improve
compatibility with web applications which don't support Firefox by this patch
since our keyCode values are really different from Chrome's. So, unfortunately,
if we'd use exactly same keyCode computation as Chromium, we'd break
compatibility with existing web applications which are aware of Firefox since
it's necessary to check UA name or something before using keyCode values.
Note that the most important difference between Windows and the others is,
such keyCode value is computed with alternative ASCII capable keyboard
layout on macOS and Linux but only on Windows, it's computed with OEM virtual
keycode. This means that only on Windows, the keyCode value may be different
from actual alternative ASCII capable keyboard layout's keyCode.
MozReview-Commit-ID: As289r9wp6i
--HG--
extra : rebase_source : 66181403dbe8ca8dab893edc8f4eec1991d544d0
2018-02-16 06:54:07 +00:00
|
|
|
case CODE_NAME_INDEX_IntlBackslash: // VK_OEM_5 on Windows (ABNT, etc)
|
|
|
|
case CODE_NAME_INDEX_IntlYen: // VK_OEM_5 on Windows (JIS)
|
|
|
|
case CODE_NAME_INDEX_IntlRo: // VK_OEM_102 on Windows
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_BACK_SLASH;
|
Bug 1036008 - Use alternative ASCII capable keyboard layout information to decide keyCode even if the key produces an ASCII punctuation character r=smaug
Gecko decides keyCode from an ASCII character which is produced by the key
by itself or with Shift on active keyboard layout or alternative ASCII capable
keyboard layout if active keyboard layout isn't ASCII capable. However, we've
ignored alternative ASCII capable keyboard layout's character if both the
key itself and with Shift don't produce ASCII alphabet nor ASCII numeral,
i.e., ASCII punctuation characters are not used in alternative ASCII capable
keyboard layout because of avoiding mapping a keyCode value to 2 or more keys.
However, setting 0 to keyCode value makes Firefox unusable with some web
applications which are aware of neither KeyboardEvent.key nor
KeyboardEvent.code. So, even if we map same keyCode value to a key, we should
avoid setting keyCode value to 0 as far as possible.
This patch's approach is, we behave same keyCode value as the alternative ASCII
capable keyCode is selected when computed keyCode value of active keyboard
layout is 0. This means that we will make some language users whose keyboard
layout for their language is not ASCII capable can use global web services
which support US keyboard layout of Firefox since the new keyCode values
are mostly computed with US layout on Windows or actual alternative ASCII
capable keyboard layout on macOS and Linux. In other words, we cannot improve
compatibility with web applications which don't support Firefox by this patch
since our keyCode values are really different from Chrome's. So, unfortunately,
if we'd use exactly same keyCode computation as Chromium, we'd break
compatibility with existing web applications which are aware of Firefox since
it's necessary to check UA name or something before using keyCode values.
Note that the most important difference between Windows and the others is,
such keyCode value is computed with alternative ASCII capable keyboard
layout on macOS and Linux but only on Windows, it's computed with OEM virtual
keycode. This means that only on Windows, the keyCode value may be different
from actual alternative ASCII capable keyboard layout's keyCode.
MozReview-Commit-ID: As289r9wp6i
--HG--
extra : rebase_source : 66181403dbe8ca8dab893edc8f4eec1991d544d0
2018-02-16 06:54:07 +00:00
|
|
|
default:
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-03-14 13:13:30 +00:00
|
|
|
/* static */ const char* WidgetKeyboardEvent::GetCommandStr(Command aCommand) {
|
|
|
|
#define NS_DEFINE_COMMAND(aName, aCommandStr) , #aCommandStr
|
Bug 1546839 - part 2: Define commands which are handled by editor r=smaug
`NS_DEFINE_COMMAND_WITH_PARAM` macro is special case for `cmd_align`.
`cmd_align` can be mapped to multiple `Command` values. It's distinguished
with additional parameter, '"left"', '"right"', '"center"' or '"justify"'.
Therefore, we cannot map from XUL command to `Command` value simply with
hashtable created by the next patch. So, this new macro is necessary for
the next patch to ignore this special case.
The used commands are listed up from:
* [converted from `execCommand`, `cmd_bold` - `cmd_superscript`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2066-2071)
* [converted from `execCommand`, `cmd_undo` - `cmd_redo`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2078-2079)
* [converted from `execCommand`, `cmd_paragraphState` - `cmd_outdent`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2080-2081,2105-2106)
* [converted from `execCommand`, `cmd_align`s](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2095-2098)
* [converted from `execCommand`, `cmd_highlight` - `cmd_decreaseFont`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2082-2088)
* [converted from `execCommand`, `cmd_insertHR` - `cmd_ul`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2089-2093,2101-2102)
* [converted from `execCommand`, `cmd_getContents` - `cmd_enableAbsolutePositionEditing`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2094,2099-2100,2107-2113)
* [internal commands, `obs_documentCreated` - `obs_documentWillBeDestroyed`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#26-28)
* [internal command, `cmd_abbr`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#68)
* [internal command, `cmd_absPos`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#102)
* [internal commands, `cmd_acronym` - `cmd_var`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#58,63,65-67,69-72)
* [internal commands, `cmd_dd` - `cmd_dt`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#78-79)
* [internal commands, `cmd_moveDown` - `cmd_selectUp2`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/EditorController.cpp#97-112)
* [internal command, `cmd_setDocumentModified`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#31)
Differential Revision: https://phabricator.services.mozilla.com/D29171
--HG--
extra : moz-landing-system : lando
2019-04-30 06:04:01 +00:00
|
|
|
#define NS_DEFINE_COMMAND_WITH_PARAM(aName, aCommandStr, aParam) , #aCommandStr
|
2021-01-29 22:26:57 +00:00
|
|
|
#define NS_DEFINE_COMMAND_NO_EXEC_COMMAND(aName) , ""
|
2016-03-11 02:57:18 +00:00
|
|
|
static const char* const kCommands[] = {
|
2019-04-30 04:23:24 +00:00
|
|
|
"" // DoNothing
|
2014-03-14 13:13:30 +00:00
|
|
|
#include "mozilla/CommandList.h"
|
|
|
|
};
|
|
|
|
#undef NS_DEFINE_COMMAND
|
Bug 1546839 - part 2: Define commands which are handled by editor r=smaug
`NS_DEFINE_COMMAND_WITH_PARAM` macro is special case for `cmd_align`.
`cmd_align` can be mapped to multiple `Command` values. It's distinguished
with additional parameter, '"left"', '"right"', '"center"' or '"justify"'.
Therefore, we cannot map from XUL command to `Command` value simply with
hashtable created by the next patch. So, this new macro is necessary for
the next patch to ignore this special case.
The used commands are listed up from:
* [converted from `execCommand`, `cmd_bold` - `cmd_superscript`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2066-2071)
* [converted from `execCommand`, `cmd_undo` - `cmd_redo`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2078-2079)
* [converted from `execCommand`, `cmd_paragraphState` - `cmd_outdent`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2080-2081,2105-2106)
* [converted from `execCommand`, `cmd_align`s](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2095-2098)
* [converted from `execCommand`, `cmd_highlight` - `cmd_decreaseFont`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2082-2088)
* [converted from `execCommand`, `cmd_insertHR` - `cmd_ul`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2089-2093,2101-2102)
* [converted from `execCommand`, `cmd_getContents` - `cmd_enableAbsolutePositionEditing`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2094,2099-2100,2107-2113)
* [internal commands, `obs_documentCreated` - `obs_documentWillBeDestroyed`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#26-28)
* [internal command, `cmd_abbr`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#68)
* [internal command, `cmd_absPos`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#102)
* [internal commands, `cmd_acronym` - `cmd_var`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#58,63,65-67,69-72)
* [internal commands, `cmd_dd` - `cmd_dt`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#78-79)
* [internal commands, `cmd_moveDown` - `cmd_selectUp2`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/EditorController.cpp#97-112)
* [internal command, `cmd_setDocumentModified`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#31)
Differential Revision: https://phabricator.services.mozilla.com/D29171
--HG--
extra : moz-landing-system : lando
2019-04-30 06:04:01 +00:00
|
|
|
#undef NS_DEFINE_COMMAND_WITH_PARAM
|
Bug 1403759 - part 2: Handle edit/selection commands like insertNewline: in TextInputHandler::HandleCommand() r=m_kato
Let's make TextInputHandler::HandleCommand() handle other
commands which are caused by Backspace, Delete, Tab, ArrowUp,
ArrowDown, ArrowRight, ArrowLeft, PageUp, PageDown, Home, End
and Escape keys with various modifiers.
This patch makes Korean users can do most key operation in
editor even with composing Hangul character.
Note that this patch has a hack for cancelOperation: command.
The command is typically fired for Escape key press. However,
it's also fired for Command + Period. Unfortunately, this
behavior is really odd if subclass of NSResponder implements
|void cancelOperation:(id)sender|. If it's implemented,
Cocoa doesn't call its |void keyDown:(NSEvent)theEvent|.
Instead, it calls only |void doCommandBySelector:(SEL)aSelector|
and |void cancelOperation:(id)sender| when Command + Period is
pressed. Therefore, we cannot dispatch keydown nor keypress
event for this key combination if we implement it. Therefore,
this patch doesn't implement the method but handle it in
doCommandBySelector even though the super class of ChildView
cannot handle the command with this path.
MozReview-Commit-ID: 4hS23SiwNJv
--HG--
extra : rebase_source : 38ac1ea494b5f786ecd5c9327efbacd460b59faf
2017-12-02 05:53:10 +00:00
|
|
|
#undef NS_DEFINE_COMMAND_NO_EXEC_COMMAND
|
2014-03-14 13:13:30 +00:00
|
|
|
|
Bug 1922838 - Replace ArrayLength, ArrayEnd and MOZ_ARRAY_LENGTH by standard alternative r=glandium,necko-reviewers,jgilbert,application-update-reviewers,media-playback-reviewers,credential-management-reviewers,anti-tracking-reviewers,places-reviewers,profiler-reviewers,win-reviewers,dom-storage-reviewers,bytesized,janv,dimi,daisuke,karlt,gstoll,canaltinova,timhuang
Namely std::size, std::end and std::size. This drops C support for
MOZ_ARRAY_LENGTH but it wasn't used anyway.
Differential Revision: https://phabricator.services.mozilla.com/D224611
2024-10-28 08:21:19 +00:00
|
|
|
MOZ_RELEASE_ASSERT(static_cast<size_t>(aCommand) < std::size(kCommands),
|
2014-03-14 13:13:30 +00:00
|
|
|
"Illegal command enumeration value");
|
2019-04-30 04:23:24 +00:00
|
|
|
return kCommands[static_cast<CommandInt>(aCommand)];
|
2014-03-14 13:13:30 +00:00
|
|
|
}
|
|
|
|
|
2019-02-25 22:13:48 +00:00
|
|
|
/* static */
|
|
|
|
uint32_t WidgetKeyboardEvent::ComputeLocationFromCodeValue(
|
2015-01-28 13:36:53 +00:00
|
|
|
CodeNameIndex aCodeNameIndex) {
|
|
|
|
// Following commented out cases are not defined in PhysicalKeyCodeNameList.h
|
|
|
|
// but are defined by D3E spec. So, they should be uncommented when the
|
|
|
|
// code values are defined in the header.
|
|
|
|
switch (aCodeNameIndex) {
|
|
|
|
case CODE_NAME_INDEX_AltLeft:
|
|
|
|
case CODE_NAME_INDEX_ControlLeft:
|
2023-08-07 01:03:58 +00:00
|
|
|
case CODE_NAME_INDEX_MetaLeft:
|
2015-01-28 13:36:53 +00:00
|
|
|
case CODE_NAME_INDEX_ShiftLeft:
|
2017-02-08 12:04:22 +00:00
|
|
|
return eKeyLocationLeft;
|
2015-01-28 13:36:53 +00:00
|
|
|
case CODE_NAME_INDEX_AltRight:
|
|
|
|
case CODE_NAME_INDEX_ControlRight:
|
2023-08-07 01:03:58 +00:00
|
|
|
case CODE_NAME_INDEX_MetaRight:
|
2015-01-28 13:36:53 +00:00
|
|
|
case CODE_NAME_INDEX_ShiftRight:
|
2017-02-08 12:04:22 +00:00
|
|
|
return eKeyLocationRight;
|
2015-01-28 13:36:53 +00:00
|
|
|
case CODE_NAME_INDEX_Numpad0:
|
|
|
|
case CODE_NAME_INDEX_Numpad1:
|
|
|
|
case CODE_NAME_INDEX_Numpad2:
|
|
|
|
case CODE_NAME_INDEX_Numpad3:
|
|
|
|
case CODE_NAME_INDEX_Numpad4:
|
|
|
|
case CODE_NAME_INDEX_Numpad5:
|
|
|
|
case CODE_NAME_INDEX_Numpad6:
|
|
|
|
case CODE_NAME_INDEX_Numpad7:
|
|
|
|
case CODE_NAME_INDEX_Numpad8:
|
|
|
|
case CODE_NAME_INDEX_Numpad9:
|
|
|
|
case CODE_NAME_INDEX_NumpadAdd:
|
|
|
|
case CODE_NAME_INDEX_NumpadBackspace:
|
2015-02-19 06:50:20 +00:00
|
|
|
case CODE_NAME_INDEX_NumpadClear:
|
|
|
|
case CODE_NAME_INDEX_NumpadClearEntry:
|
2015-01-28 13:36:53 +00:00
|
|
|
case CODE_NAME_INDEX_NumpadComma:
|
|
|
|
case CODE_NAME_INDEX_NumpadDecimal:
|
|
|
|
case CODE_NAME_INDEX_NumpadDivide:
|
|
|
|
case CODE_NAME_INDEX_NumpadEnter:
|
|
|
|
case CODE_NAME_INDEX_NumpadEqual:
|
2015-02-19 06:50:20 +00:00
|
|
|
case CODE_NAME_INDEX_NumpadMemoryAdd:
|
|
|
|
case CODE_NAME_INDEX_NumpadMemoryClear:
|
|
|
|
case CODE_NAME_INDEX_NumpadMemoryRecall:
|
|
|
|
case CODE_NAME_INDEX_NumpadMemoryStore:
|
2015-01-28 13:36:53 +00:00
|
|
|
case CODE_NAME_INDEX_NumpadMemorySubtract:
|
|
|
|
case CODE_NAME_INDEX_NumpadMultiply:
|
2015-02-19 06:50:20 +00:00
|
|
|
case CODE_NAME_INDEX_NumpadParenLeft:
|
|
|
|
case CODE_NAME_INDEX_NumpadParenRight:
|
2015-01-28 13:36:53 +00:00
|
|
|
case CODE_NAME_INDEX_NumpadSubtract:
|
2017-02-08 12:04:22 +00:00
|
|
|
return eKeyLocationNumpad;
|
2015-01-28 13:36:53 +00:00
|
|
|
default:
|
2017-02-08 12:04:22 +00:00
|
|
|
return eKeyLocationStandard;
|
2015-01-28 13:36:53 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-02-25 22:13:48 +00:00
|
|
|
/* static */
|
|
|
|
uint32_t WidgetKeyboardEvent::ComputeKeyCodeFromKeyNameIndex(
|
2015-02-19 06:50:19 +00:00
|
|
|
KeyNameIndex aKeyNameIndex) {
|
|
|
|
switch (aKeyNameIndex) {
|
|
|
|
case KEY_NAME_INDEX_Cancel:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_CANCEL;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Help:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_HELP;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Backspace:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_BACK_SPACE;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Tab:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_TAB;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Clear:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_CLEAR;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Enter:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_RETURN;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Shift:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_SHIFT;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Control:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_CONTROL;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Alt:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_ALT;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Pause:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_PAUSE;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_CapsLock:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_CAPS_LOCK;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Hiragana:
|
|
|
|
case KEY_NAME_INDEX_Katakana:
|
|
|
|
case KEY_NAME_INDEX_HiraganaKatakana:
|
|
|
|
case KEY_NAME_INDEX_KanaMode:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_KANA;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_HangulMode:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_HANGUL;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Eisu:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_EISU;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_JunjaMode:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_JUNJA;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_FinalMode:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_FINAL;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_HanjaMode:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_HANJA;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_KanjiMode:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_KANJI;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Escape:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_ESCAPE;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Convert:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_CONVERT;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_NonConvert:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_NONCONVERT;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Accept:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_ACCEPT;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_ModeChange:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_MODECHANGE;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_PageUp:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_PAGE_UP;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_PageDown:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_PAGE_DOWN;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_End:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_END;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Home:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_HOME;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_ArrowLeft:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_LEFT;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_ArrowUp:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_UP;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_ArrowRight:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_RIGHT;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_ArrowDown:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_DOWN;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Select:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_SELECT;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Print:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_PRINT;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Execute:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_EXECUTE;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_PrintScreen:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_PRINTSCREEN;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Insert:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_INSERT;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Delete:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_DELETE;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_ContextMenu:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_CONTEXT_MENU;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Standby:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_SLEEP;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F1:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F1;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F2:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F2;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F3:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F3;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F4:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F4;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F5:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F5;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F6:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F6;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F7:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F7;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F8:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F8;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F9:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F9;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F10:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F10;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F11:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F11;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F12:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F12;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F13:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F13;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F14:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F14;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F15:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F15;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F16:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F16;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F17:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F17;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F18:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F18;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F19:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F19;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F20:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F20;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F21:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F21;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F22:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F22;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F23:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F23;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_F24:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_F24;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_NumLock:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_NUM_LOCK;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_ScrollLock:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_SCROLL_LOCK;
|
2016-05-20 15:57:18 +00:00
|
|
|
case KEY_NAME_INDEX_AudioVolumeMute:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_VOLUME_MUTE;
|
2016-05-20 15:52:03 +00:00
|
|
|
case KEY_NAME_INDEX_AudioVolumeDown:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_VOLUME_DOWN;
|
2016-05-20 15:55:48 +00:00
|
|
|
case KEY_NAME_INDEX_AudioVolumeUp:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_VOLUME_UP;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Meta:
|
2023-08-07 01:03:58 +00:00
|
|
|
#if defined(XP_WIN) || defined(MOZ_WIDGET_GTK)
|
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_WIN;
|
|
|
|
#else
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_META;
|
2023-08-07 01:03:58 +00:00
|
|
|
#endif
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_AltGraph:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_ALTGR;
|
Bug 1446253 - Make EventUtils.synthesizeComposition() dispatch keydown and keyup event in default r=smaug
We'll start to dispatch keydown event and keyup event even during composition.
So, for testing those events won't break our UI, we should make
EventUtils.synhtesizeComposition() and EventUtils.synthesizeCompositionChange()
dispatch keydown event and keyup event even if callers don't specify keyboard
event explicitly.
Typically, "keydown" event is marked as "processed by IME", i.e., keyCode
value is set to DOM_VK_PROCESSKEY and key is set to "Process", with our
widget which handles native IME and key input. On the other hand, "keyup"
is NOT marked as so.
Therefore, this patch makes TextInputProcessor emulates this behavior without
any new special flags. And for making possible to emulate special cases,
this patch adds two flags to nsITextInputProcessor. One is
KEY_DONT_MARK_KEYDOWN_AS_PROCESSED. The other is KEY_MARK_KEYUP_AS_PROCESSED.
Unfortunately, those flags have opposite meaning but this must be better than
making necessary to one flag for emulating usual keydown/keyup events.
Finally, this makes some tests specify better keyboard information to
synthesizeComposition() and synthesizeCompositionChange() to emulate
actual keyboard events during composition.
MozReview-Commit-ID: ItYaXILkNQE
--HG--
extra : rebase_source : e50cc77c1efbc12686d7ea334d41926c7392b30d
2018-03-16 13:35:07 +00:00
|
|
|
case KEY_NAME_INDEX_Process:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_PROCESSKEY;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Attn:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_ATTN;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_CrSel:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_CRSEL;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_ExSel:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_EXSEL;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_EraseEof:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_EREOF;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_Play:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_PLAY;
|
2015-02-19 06:50:19 +00:00
|
|
|
case KEY_NAME_INDEX_ZoomToggle:
|
|
|
|
case KEY_NAME_INDEX_ZoomIn:
|
|
|
|
case KEY_NAME_INDEX_ZoomOut:
|
2018-06-25 21:20:54 +00:00
|
|
|
return dom::KeyboardEvent_Binding::DOM_VK_ZOOM;
|
2015-02-19 06:50:19 +00:00
|
|
|
default:
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-02-25 22:13:48 +00:00
|
|
|
/* static */
|
|
|
|
CodeNameIndex WidgetKeyboardEvent::ComputeCodeNameIndexFromKeyNameIndex(
|
2018-10-03 09:21:47 +00:00
|
|
|
KeyNameIndex aKeyNameIndex, const Maybe<uint32_t>& aLocation) {
|
|
|
|
if (aLocation.isSome() &&
|
|
|
|
aLocation.value() ==
|
|
|
|
dom::KeyboardEvent_Binding::DOM_KEY_LOCATION_NUMPAD) {
|
|
|
|
// On macOS, NumLock is not supported. Therefore, this handles
|
|
|
|
// control key values except "Enter" only on non-macOS platforms.
|
|
|
|
switch (aKeyNameIndex) {
|
|
|
|
#ifndef XP_MACOSX
|
|
|
|
case KEY_NAME_INDEX_Insert:
|
|
|
|
return CODE_NAME_INDEX_Numpad0;
|
|
|
|
case KEY_NAME_INDEX_End:
|
|
|
|
return CODE_NAME_INDEX_Numpad1;
|
|
|
|
case KEY_NAME_INDEX_ArrowDown:
|
|
|
|
return CODE_NAME_INDEX_Numpad2;
|
|
|
|
case KEY_NAME_INDEX_PageDown:
|
|
|
|
return CODE_NAME_INDEX_Numpad3;
|
|
|
|
case KEY_NAME_INDEX_ArrowLeft:
|
|
|
|
return CODE_NAME_INDEX_Numpad4;
|
|
|
|
case KEY_NAME_INDEX_Clear:
|
|
|
|
// FYI: "Clear" on macOS should be DOM_KEY_LOCATION_STANDARD.
|
|
|
|
return CODE_NAME_INDEX_Numpad5;
|
|
|
|
case KEY_NAME_INDEX_ArrowRight:
|
|
|
|
return CODE_NAME_INDEX_Numpad6;
|
|
|
|
case KEY_NAME_INDEX_Home:
|
|
|
|
return CODE_NAME_INDEX_Numpad7;
|
|
|
|
case KEY_NAME_INDEX_ArrowUp:
|
|
|
|
return CODE_NAME_INDEX_Numpad8;
|
|
|
|
case KEY_NAME_INDEX_PageUp:
|
|
|
|
return CODE_NAME_INDEX_Numpad9;
|
|
|
|
case KEY_NAME_INDEX_Delete:
|
|
|
|
return CODE_NAME_INDEX_NumpadDecimal;
|
|
|
|
#endif // #ifndef XP_MACOSX
|
|
|
|
case KEY_NAME_INDEX_Enter:
|
|
|
|
return CODE_NAME_INDEX_NumpadEnter;
|
|
|
|
default:
|
|
|
|
return CODE_NAME_INDEX_UNKNOWN;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (WidgetKeyboardEvent::IsLeftOrRightModiferKeyNameIndex(aKeyNameIndex)) {
|
|
|
|
if (aLocation.isSome() &&
|
|
|
|
(aLocation.value() !=
|
|
|
|
dom::KeyboardEvent_Binding::DOM_KEY_LOCATION_LEFT &&
|
|
|
|
aLocation.value() !=
|
|
|
|
dom::KeyboardEvent_Binding::DOM_KEY_LOCATION_RIGHT)) {
|
|
|
|
return CODE_NAME_INDEX_UNKNOWN;
|
|
|
|
}
|
|
|
|
bool isRight =
|
|
|
|
aLocation.isSome() &&
|
|
|
|
aLocation.value() == dom::KeyboardEvent_Binding::DOM_KEY_LOCATION_RIGHT;
|
|
|
|
switch (aKeyNameIndex) {
|
|
|
|
case KEY_NAME_INDEX_Alt:
|
|
|
|
return isRight ? CODE_NAME_INDEX_AltRight : CODE_NAME_INDEX_AltLeft;
|
|
|
|
case KEY_NAME_INDEX_Control:
|
|
|
|
return isRight ? CODE_NAME_INDEX_ControlRight
|
|
|
|
: CODE_NAME_INDEX_ControlLeft;
|
|
|
|
case KEY_NAME_INDEX_Shift:
|
|
|
|
return isRight ? CODE_NAME_INDEX_ShiftRight : CODE_NAME_INDEX_ShiftLeft;
|
|
|
|
case KEY_NAME_INDEX_Meta:
|
2023-08-07 01:03:58 +00:00
|
|
|
return isRight ? CODE_NAME_INDEX_MetaRight : CODE_NAME_INDEX_MetaLeft;
|
2018-10-03 09:21:47 +00:00
|
|
|
default:
|
|
|
|
return CODE_NAME_INDEX_UNKNOWN;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (aLocation.isSome() &&
|
|
|
|
aLocation.value() !=
|
|
|
|
dom::KeyboardEvent_Binding::DOM_KEY_LOCATION_STANDARD) {
|
|
|
|
return CODE_NAME_INDEX_UNKNOWN;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (aKeyNameIndex) {
|
|
|
|
// Standard section:
|
|
|
|
case KEY_NAME_INDEX_Escape:
|
|
|
|
return CODE_NAME_INDEX_Escape;
|
|
|
|
case KEY_NAME_INDEX_Tab:
|
|
|
|
return CODE_NAME_INDEX_Tab;
|
|
|
|
case KEY_NAME_INDEX_CapsLock:
|
|
|
|
return CODE_NAME_INDEX_CapsLock;
|
|
|
|
case KEY_NAME_INDEX_ContextMenu:
|
|
|
|
return CODE_NAME_INDEX_ContextMenu;
|
|
|
|
case KEY_NAME_INDEX_Backspace:
|
|
|
|
return CODE_NAME_INDEX_Backspace;
|
|
|
|
case KEY_NAME_INDEX_Enter:
|
|
|
|
return CODE_NAME_INDEX_Enter;
|
|
|
|
#ifdef XP_MACOSX
|
|
|
|
// Although, macOS does not fire native key event of "Fn" key, we support
|
|
|
|
// Fn key event if it's sent by other apps directly.
|
|
|
|
case KEY_NAME_INDEX_Fn:
|
|
|
|
return CODE_NAME_INDEX_Fn;
|
|
|
|
#endif // #ifdef
|
|
|
|
|
|
|
|
// Arrow Pad section:
|
|
|
|
case KEY_NAME_INDEX_ArrowLeft:
|
|
|
|
return CODE_NAME_INDEX_ArrowLeft;
|
|
|
|
case KEY_NAME_INDEX_ArrowUp:
|
|
|
|
return CODE_NAME_INDEX_ArrowUp;
|
|
|
|
case KEY_NAME_INDEX_ArrowDown:
|
|
|
|
return CODE_NAME_INDEX_ArrowDown;
|
|
|
|
case KEY_NAME_INDEX_ArrowRight:
|
|
|
|
return CODE_NAME_INDEX_ArrowRight;
|
|
|
|
|
|
|
|
// Control Pad section:
|
|
|
|
#ifndef XP_MACOSX
|
|
|
|
case KEY_NAME_INDEX_Insert:
|
|
|
|
return CODE_NAME_INDEX_Insert;
|
|
|
|
#else
|
|
|
|
case KEY_NAME_INDEX_Help:
|
|
|
|
return CODE_NAME_INDEX_Help;
|
|
|
|
#endif // #ifndef XP_MACOSX #else
|
|
|
|
case KEY_NAME_INDEX_Delete:
|
|
|
|
return CODE_NAME_INDEX_Delete;
|
|
|
|
case KEY_NAME_INDEX_Home:
|
|
|
|
return CODE_NAME_INDEX_Home;
|
|
|
|
case KEY_NAME_INDEX_End:
|
|
|
|
return CODE_NAME_INDEX_End;
|
|
|
|
case KEY_NAME_INDEX_PageUp:
|
|
|
|
return CODE_NAME_INDEX_PageUp;
|
|
|
|
case KEY_NAME_INDEX_PageDown:
|
|
|
|
return CODE_NAME_INDEX_PageDown;
|
|
|
|
|
|
|
|
// Function keys:
|
|
|
|
case KEY_NAME_INDEX_F1:
|
|
|
|
return CODE_NAME_INDEX_F1;
|
|
|
|
case KEY_NAME_INDEX_F2:
|
|
|
|
return CODE_NAME_INDEX_F2;
|
|
|
|
case KEY_NAME_INDEX_F3:
|
|
|
|
return CODE_NAME_INDEX_F3;
|
|
|
|
case KEY_NAME_INDEX_F4:
|
|
|
|
return CODE_NAME_INDEX_F4;
|
|
|
|
case KEY_NAME_INDEX_F5:
|
|
|
|
return CODE_NAME_INDEX_F5;
|
|
|
|
case KEY_NAME_INDEX_F6:
|
|
|
|
return CODE_NAME_INDEX_F6;
|
|
|
|
case KEY_NAME_INDEX_F7:
|
|
|
|
return CODE_NAME_INDEX_F7;
|
|
|
|
case KEY_NAME_INDEX_F8:
|
|
|
|
return CODE_NAME_INDEX_F8;
|
|
|
|
case KEY_NAME_INDEX_F9:
|
|
|
|
return CODE_NAME_INDEX_F9;
|
|
|
|
case KEY_NAME_INDEX_F10:
|
|
|
|
return CODE_NAME_INDEX_F10;
|
|
|
|
case KEY_NAME_INDEX_F11:
|
|
|
|
return CODE_NAME_INDEX_F11;
|
|
|
|
case KEY_NAME_INDEX_F12:
|
|
|
|
return CODE_NAME_INDEX_F12;
|
|
|
|
case KEY_NAME_INDEX_F13:
|
|
|
|
return CODE_NAME_INDEX_F13;
|
|
|
|
case KEY_NAME_INDEX_F14:
|
|
|
|
return CODE_NAME_INDEX_F14;
|
|
|
|
case KEY_NAME_INDEX_F15:
|
|
|
|
return CODE_NAME_INDEX_F15;
|
|
|
|
case KEY_NAME_INDEX_F16:
|
|
|
|
return CODE_NAME_INDEX_F16;
|
|
|
|
case KEY_NAME_INDEX_F17:
|
|
|
|
return CODE_NAME_INDEX_F17;
|
|
|
|
case KEY_NAME_INDEX_F18:
|
|
|
|
return CODE_NAME_INDEX_F18;
|
|
|
|
case KEY_NAME_INDEX_F19:
|
|
|
|
return CODE_NAME_INDEX_F19;
|
|
|
|
case KEY_NAME_INDEX_F20:
|
|
|
|
return CODE_NAME_INDEX_F20;
|
|
|
|
#ifndef XP_MACOSX
|
|
|
|
case KEY_NAME_INDEX_F21:
|
|
|
|
return CODE_NAME_INDEX_F21;
|
|
|
|
case KEY_NAME_INDEX_F22:
|
|
|
|
return CODE_NAME_INDEX_F22;
|
|
|
|
case KEY_NAME_INDEX_F23:
|
|
|
|
return CODE_NAME_INDEX_F23;
|
|
|
|
case KEY_NAME_INDEX_F24:
|
|
|
|
return CODE_NAME_INDEX_F24;
|
|
|
|
case KEY_NAME_INDEX_Pause:
|
|
|
|
return CODE_NAME_INDEX_Pause;
|
|
|
|
case KEY_NAME_INDEX_PrintScreen:
|
|
|
|
return CODE_NAME_INDEX_PrintScreen;
|
|
|
|
case KEY_NAME_INDEX_ScrollLock:
|
|
|
|
return CODE_NAME_INDEX_ScrollLock;
|
|
|
|
#endif // #ifndef XP_MACOSX
|
|
|
|
|
|
|
|
// NumLock key:
|
|
|
|
#ifndef XP_MACOSX
|
|
|
|
case KEY_NAME_INDEX_NumLock:
|
|
|
|
return CODE_NAME_INDEX_NumLock;
|
|
|
|
#else
|
|
|
|
case KEY_NAME_INDEX_Clear:
|
|
|
|
return CODE_NAME_INDEX_NumLock;
|
|
|
|
#endif // #ifndef XP_MACOSX #else
|
|
|
|
|
|
|
|
// Media keys:
|
|
|
|
case KEY_NAME_INDEX_AudioVolumeDown:
|
|
|
|
return CODE_NAME_INDEX_VolumeDown;
|
|
|
|
case KEY_NAME_INDEX_AudioVolumeMute:
|
|
|
|
return CODE_NAME_INDEX_VolumeMute;
|
|
|
|
case KEY_NAME_INDEX_AudioVolumeUp:
|
|
|
|
return CODE_NAME_INDEX_VolumeUp;
|
|
|
|
#ifndef XP_MACOSX
|
|
|
|
case KEY_NAME_INDEX_BrowserBack:
|
|
|
|
return CODE_NAME_INDEX_BrowserBack;
|
|
|
|
case KEY_NAME_INDEX_BrowserFavorites:
|
|
|
|
return CODE_NAME_INDEX_BrowserFavorites;
|
|
|
|
case KEY_NAME_INDEX_BrowserForward:
|
|
|
|
return CODE_NAME_INDEX_BrowserForward;
|
|
|
|
case KEY_NAME_INDEX_BrowserRefresh:
|
|
|
|
return CODE_NAME_INDEX_BrowserRefresh;
|
|
|
|
case KEY_NAME_INDEX_BrowserSearch:
|
|
|
|
return CODE_NAME_INDEX_BrowserSearch;
|
|
|
|
case KEY_NAME_INDEX_BrowserStop:
|
|
|
|
return CODE_NAME_INDEX_BrowserStop;
|
|
|
|
case KEY_NAME_INDEX_MediaPlayPause:
|
|
|
|
return CODE_NAME_INDEX_MediaPlayPause;
|
|
|
|
case KEY_NAME_INDEX_MediaStop:
|
|
|
|
return CODE_NAME_INDEX_MediaStop;
|
|
|
|
case KEY_NAME_INDEX_MediaTrackNext:
|
|
|
|
return CODE_NAME_INDEX_MediaTrackNext;
|
|
|
|
case KEY_NAME_INDEX_MediaTrackPrevious:
|
|
|
|
return CODE_NAME_INDEX_MediaTrackPrevious;
|
|
|
|
case KEY_NAME_INDEX_LaunchApplication1:
|
|
|
|
return CODE_NAME_INDEX_LaunchApp1;
|
|
|
|
#endif // #ifndef XP_MACOSX
|
|
|
|
|
|
|
|
// Only Windows and GTK supports the following multimedia keys.
|
|
|
|
#if defined(XP_WIN) || defined(MOZ_WIDGET_GTK)
|
|
|
|
case KEY_NAME_INDEX_BrowserHome:
|
|
|
|
return CODE_NAME_INDEX_BrowserHome;
|
|
|
|
case KEY_NAME_INDEX_LaunchApplication2:
|
|
|
|
return CODE_NAME_INDEX_LaunchApp2;
|
|
|
|
#endif // #if defined(XP_WIN) || defined(MOZ_WIDGET_GTK)
|
|
|
|
|
|
|
|
// Only GTK and Android supports the following multimedia keys.
|
|
|
|
#if defined(MOZ_WIDGET_GTK) || defined(ANDROID)
|
|
|
|
case KEY_NAME_INDEX_Eject:
|
|
|
|
return CODE_NAME_INDEX_Eject;
|
|
|
|
case KEY_NAME_INDEX_WakeUp:
|
|
|
|
return CODE_NAME_INDEX_WakeUp;
|
|
|
|
#endif // #if defined(MOZ_WIDGET_GTK) || defined(ANDROID)
|
|
|
|
|
|
|
|
// Only Windows does not support Help key (and macOS handled above).
|
|
|
|
#if !defined(XP_WIN) && !defined(XP_MACOSX)
|
|
|
|
case KEY_NAME_INDEX_Help:
|
|
|
|
return CODE_NAME_INDEX_Help;
|
|
|
|
#endif // #if !defined(XP_WIN) && !defined(XP_MACOSX)
|
|
|
|
|
|
|
|
// IME specific keys:
|
|
|
|
#ifdef XP_WIN
|
|
|
|
case KEY_NAME_INDEX_Convert:
|
|
|
|
return CODE_NAME_INDEX_Convert;
|
|
|
|
case KEY_NAME_INDEX_NonConvert:
|
|
|
|
return CODE_NAME_INDEX_NonConvert;
|
|
|
|
case KEY_NAME_INDEX_Alphanumeric:
|
|
|
|
return CODE_NAME_INDEX_CapsLock;
|
|
|
|
case KEY_NAME_INDEX_KanaMode:
|
|
|
|
case KEY_NAME_INDEX_Romaji:
|
|
|
|
case KEY_NAME_INDEX_Katakana:
|
|
|
|
case KEY_NAME_INDEX_Hiragana:
|
|
|
|
return CODE_NAME_INDEX_KanaMode;
|
|
|
|
case KEY_NAME_INDEX_Hankaku:
|
|
|
|
case KEY_NAME_INDEX_Zenkaku:
|
|
|
|
case KEY_NAME_INDEX_KanjiMode:
|
|
|
|
return CODE_NAME_INDEX_Backquote;
|
|
|
|
case KEY_NAME_INDEX_HanjaMode:
|
|
|
|
return CODE_NAME_INDEX_Lang2;
|
|
|
|
case KEY_NAME_INDEX_HangulMode:
|
|
|
|
return CODE_NAME_INDEX_Lang1;
|
|
|
|
#endif // #ifdef XP_WIN
|
|
|
|
|
|
|
|
#ifdef MOZ_WIDGET_GTK
|
|
|
|
case KEY_NAME_INDEX_Convert:
|
|
|
|
return CODE_NAME_INDEX_Convert;
|
|
|
|
case KEY_NAME_INDEX_NonConvert:
|
|
|
|
return CODE_NAME_INDEX_NonConvert;
|
|
|
|
case KEY_NAME_INDEX_Alphanumeric:
|
|
|
|
return CODE_NAME_INDEX_CapsLock;
|
|
|
|
case KEY_NAME_INDEX_HiraganaKatakana:
|
|
|
|
return CODE_NAME_INDEX_KanaMode;
|
|
|
|
case KEY_NAME_INDEX_ZenkakuHankaku:
|
|
|
|
return CODE_NAME_INDEX_Backquote;
|
|
|
|
#endif // #ifdef MOZ_WIDGET_GTK
|
|
|
|
|
|
|
|
#ifdef ANDROID
|
|
|
|
case KEY_NAME_INDEX_Convert:
|
|
|
|
return CODE_NAME_INDEX_Convert;
|
|
|
|
case KEY_NAME_INDEX_NonConvert:
|
|
|
|
return CODE_NAME_INDEX_NonConvert;
|
|
|
|
case KEY_NAME_INDEX_HiraganaKatakana:
|
|
|
|
return CODE_NAME_INDEX_KanaMode;
|
|
|
|
case KEY_NAME_INDEX_ZenkakuHankaku:
|
|
|
|
return CODE_NAME_INDEX_Backquote;
|
|
|
|
case KEY_NAME_INDEX_Eisu:
|
|
|
|
return CODE_NAME_INDEX_Lang2;
|
|
|
|
case KEY_NAME_INDEX_KanjiMode:
|
|
|
|
return CODE_NAME_INDEX_Lang1;
|
|
|
|
#endif // #ifdef ANDROID
|
|
|
|
|
|
|
|
#ifdef XP_MACOSX
|
|
|
|
case KEY_NAME_INDEX_Eisu:
|
|
|
|
return CODE_NAME_INDEX_Lang2;
|
|
|
|
case KEY_NAME_INDEX_KanjiMode:
|
|
|
|
return CODE_NAME_INDEX_Lang1;
|
|
|
|
#endif // #ifdef XP_MACOSX
|
|
|
|
|
|
|
|
default:
|
|
|
|
return CODE_NAME_INDEX_UNKNOWN;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-02-25 22:13:48 +00:00
|
|
|
/* static */
|
|
|
|
Modifier WidgetKeyboardEvent::GetModifierForKeyName(
|
2015-02-19 06:50:19 +00:00
|
|
|
KeyNameIndex aKeyNameIndex) {
|
|
|
|
switch (aKeyNameIndex) {
|
|
|
|
case KEY_NAME_INDEX_Alt:
|
|
|
|
return MODIFIER_ALT;
|
|
|
|
case KEY_NAME_INDEX_AltGraph:
|
|
|
|
return MODIFIER_ALTGRAPH;
|
|
|
|
case KEY_NAME_INDEX_CapsLock:
|
|
|
|
return MODIFIER_CAPSLOCK;
|
|
|
|
case KEY_NAME_INDEX_Control:
|
|
|
|
return MODIFIER_CONTROL;
|
|
|
|
case KEY_NAME_INDEX_Fn:
|
|
|
|
return MODIFIER_FN;
|
|
|
|
case KEY_NAME_INDEX_FnLock:
|
|
|
|
return MODIFIER_FNLOCK;
|
|
|
|
// case KEY_NAME_INDEX_Hyper:
|
|
|
|
case KEY_NAME_INDEX_Meta:
|
|
|
|
return MODIFIER_META;
|
|
|
|
case KEY_NAME_INDEX_NumLock:
|
|
|
|
return MODIFIER_NUMLOCK;
|
|
|
|
case KEY_NAME_INDEX_ScrollLock:
|
|
|
|
return MODIFIER_SCROLLLOCK;
|
|
|
|
case KEY_NAME_INDEX_Shift:
|
|
|
|
return MODIFIER_SHIFT;
|
|
|
|
// case KEY_NAME_INDEX_Super:
|
|
|
|
case KEY_NAME_INDEX_Symbol:
|
|
|
|
return MODIFIER_SYMBOL;
|
|
|
|
case KEY_NAME_INDEX_SymbolLock:
|
|
|
|
return MODIFIER_SYMBOLLOCK;
|
|
|
|
default:
|
|
|
|
return MODIFIER_NONE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-02-25 22:13:48 +00:00
|
|
|
/* static */
|
|
|
|
bool WidgetKeyboardEvent::IsLockableModifier(KeyNameIndex aKeyNameIndex) {
|
2015-02-19 06:50:19 +00:00
|
|
|
switch (aKeyNameIndex) {
|
|
|
|
case KEY_NAME_INDEX_CapsLock:
|
|
|
|
case KEY_NAME_INDEX_FnLock:
|
|
|
|
case KEY_NAME_INDEX_NumLock:
|
|
|
|
case KEY_NAME_INDEX_ScrollLock:
|
|
|
|
case KEY_NAME_INDEX_SymbolLock:
|
|
|
|
return true;
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-01-07 10:10:57 +00:00
|
|
|
/******************************************************************************
|
|
|
|
* mozilla::InternalEditorInputEvent (TextEvents.h)
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
#define NS_DEFINE_INPUTTYPE(aCPPName, aDOMName) (u"" aDOMName),
|
|
|
|
const char16_t* const InternalEditorInputEvent::kInputTypeNames[] = {
|
|
|
|
#include "mozilla/InputTypeList.h"
|
|
|
|
};
|
|
|
|
#undef NS_DEFINE_INPUTTYPE
|
|
|
|
|
|
|
|
InternalEditorInputEvent::InputTypeHashtable*
|
|
|
|
InternalEditorInputEvent::sInputTypeHashtable = nullptr;
|
|
|
|
|
2019-02-25 22:13:48 +00:00
|
|
|
/* static */
|
|
|
|
void InternalEditorInputEvent::Shutdown() {
|
2019-01-07 10:10:57 +00:00
|
|
|
delete sInputTypeHashtable;
|
|
|
|
sInputTypeHashtable = nullptr;
|
|
|
|
}
|
|
|
|
|
2019-02-25 22:13:48 +00:00
|
|
|
/* static */
|
|
|
|
void InternalEditorInputEvent::GetDOMInputTypeName(EditorInputType aInputType,
|
|
|
|
nsAString& aInputTypeName) {
|
2019-01-07 10:10:57 +00:00
|
|
|
if (static_cast<size_t>(aInputType) >=
|
|
|
|
static_cast<size_t>(EditorInputType::eUnknown)) {
|
|
|
|
aInputTypeName.Truncate();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
MOZ_RELEASE_ASSERT(
|
Bug 1922838 - Replace ArrayLength, ArrayEnd and MOZ_ARRAY_LENGTH by standard alternative r=glandium,necko-reviewers,jgilbert,application-update-reviewers,media-playback-reviewers,credential-management-reviewers,anti-tracking-reviewers,places-reviewers,profiler-reviewers,win-reviewers,dom-storage-reviewers,bytesized,janv,dimi,daisuke,karlt,gstoll,canaltinova,timhuang
Namely std::size, std::end and std::size. This drops C support for
MOZ_ARRAY_LENGTH but it wasn't used anyway.
Differential Revision: https://phabricator.services.mozilla.com/D224611
2024-10-28 08:21:19 +00:00
|
|
|
static_cast<size_t>(aInputType) < std::size(kInputTypeNames),
|
2019-01-07 10:10:57 +00:00
|
|
|
"Illegal input type enumeration value");
|
|
|
|
aInputTypeName.Assign(kInputTypeNames[static_cast<size_t>(aInputType)]);
|
|
|
|
}
|
|
|
|
|
2019-02-25 22:13:48 +00:00
|
|
|
/* static */
|
|
|
|
EditorInputType InternalEditorInputEvent::GetEditorInputType(
|
2019-01-07 10:10:57 +00:00
|
|
|
const nsAString& aInputType) {
|
|
|
|
if (aInputType.IsEmpty()) {
|
|
|
|
return EditorInputType::eUnknown;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!sInputTypeHashtable) {
|
Bug 1922838 - Replace ArrayLength, ArrayEnd and MOZ_ARRAY_LENGTH by standard alternative r=glandium,necko-reviewers,jgilbert,application-update-reviewers,media-playback-reviewers,credential-management-reviewers,anti-tracking-reviewers,places-reviewers,profiler-reviewers,win-reviewers,dom-storage-reviewers,bytesized,janv,dimi,daisuke,karlt,gstoll,canaltinova,timhuang
Namely std::size, std::end and std::size. This drops C support for
MOZ_ARRAY_LENGTH but it wasn't used anyway.
Differential Revision: https://phabricator.services.mozilla.com/D224611
2024-10-28 08:21:19 +00:00
|
|
|
sInputTypeHashtable = new InputTypeHashtable(std::size(kInputTypeNames));
|
|
|
|
for (size_t i = 0; i < std::size(kInputTypeNames); i++) {
|
2021-02-26 09:11:46 +00:00
|
|
|
sInputTypeHashtable->InsertOrUpdate(nsDependentString(kInputTypeNames[i]),
|
|
|
|
static_cast<EditorInputType>(i));
|
2019-01-07 10:10:57 +00:00
|
|
|
}
|
|
|
|
}
|
2021-02-26 09:22:53 +00:00
|
|
|
return sInputTypeHashtable->MaybeGet(aInputType)
|
|
|
|
.valueOr(EditorInputType::eUnknown);
|
2019-01-07 10:10:57 +00:00
|
|
|
}
|
|
|
|
|
2013-09-24 10:04:16 +00:00
|
|
|
} // namespace mozilla
|