This patch implements InputType.inputType which is declared by Input Events.
The attribute has already been implemented by Chrome and Safari. Chrome
implements Input Events Level 1, but Safari implements Input Events Level 2.
Difference between them is only whether it supports "insertFromComposition",
"deleteByComposition" and "deleteCompositionText". This patch makes the
level switchable with pref and takes Level 1 by default because Level 2 is
still unstable around event order with composition events.
For reducing string copy cost at dispatching "input" event, this patch
makes EditorInternalInputEvent store valid input-type as enum class,
EditorInputType and resolves it to string value when
dom::InputEvent::GetInputType() is called. Note that the reason why
this patch names the enum class as EditorInputType is, there is InputType
enum class already for avoiding conflict the name, this appends "Editor"
prefix because "input" and "beforeinput" events are fired only when an
editor has focus.
Differential Revision: https://phabricator.services.mozilla.com/D14128
--HG--
extra : moz-landing-system : lando
Because of that the isPrimary of mouse pointer events will always be
true. So, we suppress other events that have isPrimary as false when
fingerprinting resistance is enabled.
Depends on D6003
Differential Revision: https://phabricator.services.mozilla.com/D6004
--HG--
extra : moz-landing-system : lando
EventStateManager needs to handle middle click paste without editor.
Therefore, the handler should be in EventStateManager.
Differential Revision: https://phabricator.services.mozilla.com/D7852
--HG--
extra : moz-landing-system : lando
We need to port synthesizeKey() of EventUtils.js to FuzzingFunctions. So,
its helper function, _guessCodeFromKeyName() in EventUtils.js needs to be
accessible from FuzzingFunctions. Therefore, we need to reimplement it
with C++ and make it accessible via nsITextInputProcessor for EventUtils.js
for making easier to maintain.
This patch moves _guessCodeFromKeyName() into TextInputProcessor and
WidgetKeyboardEvent. Non-printable key part of _guessCodeFromKeyName() is
moved to WidgetKeyboardEvent::ComputeCodeNameIndexFromKeyNameIndex() because
of not depending on active keyboard layout. On the other hand, printable
key part needs to assume that active keyboard layout is en-US keyboard layout.
Therefore, it's moved to
TextInputProcessor::GuessCodeValueOfPrintableKeyInUSEnglishKeyboardLayout()
because any Core code shouldn't refer it as utility method for keeping that
we're i18n-aware.
Differential Revision: https://phabricator.services.mozilla.com/D5514
--HG--
extra : moz-landing-system : lando
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
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
This patch makes 'Shift', 'Alt', 'Contorl' and 'AltGraph' been suppressed for content
when fingerprinting resistance is enabled. Chrome can still get these events.
The reason behind this is that websites can still observe key combinations to
tell which keyboard layout is using even we spoof the keyboardEvent.code,
keyboardEvent.keyCode and modifier states. For example, the AZERTY France
keyboard, the digit keys of it requires the user press the Shift key. So, it is
easy to differentiate AZERTY and QWERTY keyboard by observing whether a Shift key
generates its own before the digit keys. There are similar issues for 'Alt' and
'AltGraph' as well.
MozReview-Commit-ID: 3CwCgvey4lK
--HG--
extra : rebase_source : 225a34ab188f6cca288a6c0e9874261df7db629f
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
Currently, we handle insertNewline: of NSResponder with
TextInputHandler::InsertNewline(). However, its
implementation is useful for handling some other
commands. So, let's rename it to HandleCommand() and
make it take Command as its argument for handling
specific behavior of each command.
MozReview-Commit-ID: GgzQdTlVtYl
--HG--
extra : rebase_source : e1d1c8617897d29eb10ba62708e3549a77c6ee59
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
Prevent default on pointerdown will stop firing the subsequent mouse events. Ignore the case that preventDefault by WebExtensions to avoid breaking some websites.
MozReview-Commit-ID: 9ztW1WfEg9a
nsMenuBarListener::KeyPress() is eKeyEvent listener in the system event group. If the target is a remote process, it shouldn't handle accesskey immediately because preceding eKeyDown event may be consumed in the remote process or eKeyPress event itself may be consumed in the remote process.
This patch makes nsMenuBarListener::KeyPress() mark eKeyPress event as "waiting reply from remote process" only when the event matches with a menu item's accesskey and it will be send to a remote process later. Then, reply event should be handled in this method if it's available.
MozReview-Commit-ID: KOpCVgElnca
--HG--
extra : rebase_source : 881ec01f5c8e21c790bf9a8c3167d6c3f932524a
EventStateManager checks if every keypress event's modifiers match with access key modifiers which are in prefs. Moving related methods of this to WidgetKeyboardEvent makes EventStateManager simpler and we can hide the NS_MODIFIER_* constants (they may make developers confused between Modifiers of WidgetInputEvent) into WidgetEventImpl.cpp.
MozReview-Commit-ID: 23NUQ51lJ1M
--HG--
extra : rebase_source : 341f3764ef62575577572d8b349159e2d5512b26
Currently, we have 2 bool flags (and optional 2 bool flags with related purpose) for managing propagation state between parent process and remote process. However, it's really complicated. Actually, setting these flags and referring the flags is usually follow explanation.
So, for making simpler, WidgetEvent and BaseEventFlags should have some utility methods for making them as self documented code.
This patch moves WidgetKeyboardEvent::mIsReserved to BaseEventFlags::mIsReservedByChrome. That allows us to manage the cross process event propagation state in same place.
MozReview-Commit-ID: IXEDQJ4GpAZ
--HG--
extra : rebase_source : 5b63ac4f1d15e40e8bfc88423e336de28caa8ab6
Every event type handled by APZ needs to have a InputData type. This commit
adds a new KeyboardInput type that stores the minimum fields needed to match
keyboard shortcuts.
MozReview-Commit-ID: 3KUnH4sWrST
--HG--
extra : rebase_source : 710274199a1ced0716abe02e9d6aaea0d31c9498
PBrowser::RequestNativeKeyBindings() is used only when somebody tries to
execute native key bindings for synthesized keyboard events. Therefore, it
doesn't need to retrieve edit commands for all editor types. Instead, it
should take the editor type and just return the edit commands for it.
MozReview-Commit-ID: HF4Gz99SBQP
--HG--
extra : rebase_source : e332d2ef5ae36949a9a362d8f95c5d427c9812e7
Now, nsIWidget::ExecuteNativeKeyBinding() isn't used by anybody for executing
edit commands. Instead, they need array of edit commands for the key
combination. So, the method should be renamed to GetEditCommands() and just
return edit commands as an array.
MozReview-Commit-ID: 4G0B1lJ8Lbe
--HG--
extra : rebase_source : 4a5829281d59677c773950c34d91a1cd8074d243
When eKeyPress event is dispatched from TabParent to a remote process, it
should store edit command for all editor types. Then, copied
WidgetKeyboardEvent in the remote process doesn't need to request the edit
commands when its ExecuteEditCommands() is called.
Note that this patch also changes a automated test, browser_bug1316330.js,
that uses nsIDOMWindowUtils.dispatchDOMEventViaPresShell() to dispatch
repeated keyboard events in the tab. However, it should use synthesizeKey()
to emulate everything of native keyboard events and the API can dispatch
repeated keyboard events too. (And the test has a bug. It tries to wait 0.5
sec when every keydown or keypress event. However, it fails since startTime
is never initialized. This patch fixes this bug too.)
MozReview-Commit-ID: IYhyxqH3Ch8
--HG--
extra : rebase_source : 0db911e8e6ea7fc537bda76f4cc0f8952cc13dd2
Currently, edit commands for native key bindings are stored in widget. This is
stateful and really complicated in content process because it needs to cache
them.
We can make this simpler if we make WidgetKeyboardEvent store edit commands for
the key combination. Then, child process can handle it even if it's delayed
event or it's a nested event.
This patch adds arrays to WidgetKeyboardEvent to store edit commands which are
initialized with nsIWidget::ExecuteNativeKeyBinding() and adds
WidgetKeyboardEvent::ExecuteEditCommands() to execute stored edit commands as
same as nsIWidget::ExecutenativeKeyBinding().
MozReview-Commit-ID: BGRvBrLz5lp
--HG--
extra : rebase_source : b7ecd704d9c331ca1e0aedc66f230114015b853b
Currently, we use alias NS_VK_* for WidgetKeyboardEvent::mKeyCode. Similarly, we should create alias enum for nsIDOMKeyEvent::DOM_KEY_LOCATION_*. Then, we can reduce the length and avoid to include nsIDOMKeyEvent in some cpp files.
MozReview-Commit-ID: 5cs4zQ061Lc
--HG--
extra : rebase_source : e6a6edd27718b9e3d4a40b07902d029791876999
It doesn't make sense to check this in a static method of EventStateManager.cpp. Instead, it should be a class method of WidgetEvent. Then, everybody can check this in everywhere.
This patch adds mFlags.mNoCrossProcessBoundaryForwarding because when it's true, any events shouldn't be sent to remote process.
MozReview-Commit-ID: oCuxAwotDA
--HG--
extra : rebase_source : 0de8d65f83924859a38c513aff8da17d8571774d
This patch adds a new non-DOM event type, "mousetouchdrag". The name is horrible, I
know. The "mouse" comes from the fact that it's a WidgetMouseEvent, and the
"touchdrag" comes from the fact that this event is fired at the start of a touch
gesture for drag-and-drop. Right now this event is only fired from the Windows
widget code, when we receive a touch-source doubleclick event from the OS. This
event is sent to us from the OS when it detects the sequence "touchstart, touchend,
touchstart" within certain time/distance constraints. Eventually we may detect
similar gestures for other platforms in the APZ GestureEventListener and dispatch
the "mousetouchdrag" event for those as well.
The only effect of this event is that it begins tracking a drag gesture in the
EventStateManager. Subsequent touchmove events can begin the actual drag-and-drop
operation by calling ::DoDragDrop. See the discussion in bug 1147335 for some
important caveats about DoDragDrop and how it only works with left-mouse-button
events (real or synthetic).
MozReview-Commit-ID: bGyOk6dRoJ
After click events with button 2 or 3 are fired, fire auxclick, a new
event intended to represent a non-primary mouse click. Because this
event, based on the design examples and blink's implementation, is
intended to be used with content listeners, always dispatch on content
listeners--not just those that force all events to be dispatched (i.e.
document/window). This diverges from the behavior of our click events
from non-primary buttons.
Eventually, we hope this will replace click events for non-primary
buttons. For now, leave those events for compatibility reasons.
Additionally, add handling of this new event, where necessary.
MozReview-Commit-ID: 8osozM4h6Ya
--HG--
extra : rebase_source : 558261dd0d0b9241efa84ca168c50455850af03a
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
Masayuki Nakano
Sylvestre Ledru
Tim Huang
Jeff Gilbert
Boris Zbarsky
Olli Pettay
Margareta Eliza Balazs
Andreea Pavel
James Willcox
Neil Deakin
Stone Shih
Ryan Hunt
Kartikaya Gupta
Kevin Wern
David Anderson
Chris Peterson
Jimmy Wang
Carsten "Tomcat" Book