In most cases, `InputEvent.getTargetRange()` of `beforeinput` event should
return `Selection` ranges at dispatching the event.
This patch also handles special cases.
* composition change - target range should be the previous composition string
which will be replaced with new composition string.
* replace text - target range should be the replace range. This is used by
spellchecker.
* drop - target range should be the drop point.
However, the other exception is not handled by this patch. That is, deletions.
The target range(s) should be the range(s) which will be removed. In most
cases, they also matches selection ranges, but may be extended to:
* surrogate pair boundary
* grapheme cluster boundary like complex emoji
* word/line deletion deletion
* `Backspace` or `Delete` from collapsed selection
* to end of unnecessary whitespaces
For supporting these cases, we need to separate
`HTMLEditor::HandleDeleteSelection()` and its helper methods and helper class
to range computation part and modifying the DOM tree part. Of course, it
requires big changes and `InputEvent.getTargetRanges()` may be important for
feature detection of `beforeinput` event so that we should put off the big
changes to bug 1618457.
Differential Revision: https://phabricator.services.mozilla.com/D64730
--HG--
extra : moz-landing-system : lando
`InputEvent.getTargetRanges()` can be used only when event type is
`beforeinput`. So, it may be used for feature detection of `beforeinput`
event because Chrome does not implement `onbeforeinput` event handler attribute.
Therefore, this patch makes it behind the pref for `beforeinput` event.
Differential Revision: https://phabricator.services.mozilla.com/D64728
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55444
--HG--
extra : moz-landing-system : lando
The reason of the crash is, the window may have already been destroyed and
`PuppetWidget::mBrowserChild` was set to `nullptr` when synthesizing key event.
This patch makes `PuppetWidget::GetEditCommands()` check whether it's `nullptr`
and returns whether it's succeeded or not. Therefore, `TextInputProcessor`
can throw exception in such case.
Differential Revision: https://phabricator.services.mozilla.com/D52308
--HG--
extra : moz-landing-system : lando
Converts ui.key.generalAccessKey, ui.key.chromeAccess, and ui.key.contentAccess to static prefs. Updates usages.
Differential Revision: https://phabricator.services.mozilla.com/D42392
--HG--
extra : moz-landing-system : lando
`nsChildView::GetEditorView()` is called by `TextInputHandlerBase::GetWindowLevel()`
which is called when Cocoa requests window level of focused widget.
It currently gets widget including focused element (e.g., it may be in a XUL
`<panel>`) with `eQueryTextContent` event. However, it requires only the widget
(i.e., when a XUL `<panel>` has focused element, the widget for the panel).
Therefore, it does not require to flush the layout.
However, on macOS, `ContentEventHandler` always flushes layout even with
`eQueryContentState` which does not require any layout information. Whether
it requires flushing layout or not is considered with
`WidgetQueryContentEvent::mNeedsToFlushLayout` but this is set to false only
when `IMEContentObserver` notifies widget (and IME) of focus set. At this
time, only on macOS, IME caches the layout information, for example, the
character coordinates, but we don't have a way to update it. This is the reason
why we always flush layout on macOS.
Unfortunately, when a menu popup frame is created, widget for the popup is
created synchronously. Then, Cocoa retrieves window level of the widget including
focused element. But this is unsafe to flush the layout. So, we need to stop
flushing layout in this case.
Therefore, this patch moves the `#ifdef` from `TextEvents.h` to
`IMEContentObserver.cpp`, then, makes `nsChildView::GetEditorView()` use
`eQueryContentState` which is the simplest query content event, and finally,
sets `mNeedsToFlushLayout` to `false`.
Differential Revision: https://phabricator.services.mozilla.com/D25912
--HG--
extra : moz-landing-system : lando
`PresShell::EventHandler::HandleEventInternal()` may handle `Escape` key before
dispatching it in some cases. This requires too many lines for somebody who
investigate the method for the other events. Therefore, this patch moves it
into the new method.
Additionally, this patch creates `WidgetKeyboardEvent::CanTreatAsUserInput()`
and `WidgetKeyboardEvent::ShouldInteractionTimeRecorded()` because we should
manage similar checks in one place (we already have
`WidgetKeyboardEvent::CanUserGestureActivateTarget()`). Finally, their
conditions are not enough for what the comment wants to do there since they do
not check some modifier keys. Therefore, this patch makes them check all
possible modifier keys too.
Differential Revision: https://phabricator.services.mozilla.com/D21340
--HG--
extra : moz-landing-system : lando
`carriage return` and `space` are common keys which user might use to start media, so we should take account them as supported user gesture inputs.
As their pseudo char code are zero, we have to check their key code in order to distinguish them from other controls keys such as shift, alt...
Differential Revision: https://phabricator.services.mozilla.com/D21253
--HG--
extra : moz-landing-system : lando
InputEvent.dataTransfer is declared by Input Events Level 1 and Level 2 (i.e.,
not UI Events). It's necessary for "beforeinput" event on contenteditable
elements because of with some InputEvent.inputType values on contenteditable,
InputEvent.dataTransfer is used instead of InputEvent.data.
According to the Chrome's behavior, if InputEvent.dataTransfer is created by
web apps, the DataTransfer object is mutable. Otherwise, i.e., the event
represents user input, the DataTransfer object is read only. We should follow
this behavior.
This is enabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D19296
--HG--
extra : moz-landing-system : lando
InputEvent.data notifies web apps of inserting/inserted text with "beforeinput"
and "input" events. So, this is important especially for "beforeinput" event
listeners. That's the reason why we need to support this before implementing
"beforeinput" event.
This patch adds it into InputEvent and make it enabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D19285
--HG--
extra : moz-landing-system : lando
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
This patch re-enables the new behavior of bug 1479964, to set keyCode or
charCode of keypress event whose value is zero to the other's non-zero value.
However, some web apps are still broken with the new behavior. Therefore,
this patch adds a blacklist to keep using our legacy behavior in some specific
web apps.
Note that Google Docs, Gmail and Remember The Milk are reported as broken.
However, I don't see any broken shortcut with Gmail. Therefore, this patch
adds only Google Docs and Remeber The Milk into the blacklist.
Differential Revision: https://phabricator.services.mozilla.com/D10322
--HG--
extra : moz-landing-system : lando
Synthesizing keyboard events is dangerous and such API is requested only by
fuzzing test. So, we should add it into FuzzingFunctions which is built
only when |ac_add_options --enable-fuzzing| is specified and enabled by
the pref.
This patch implements the API as synthesizing keyboard events in the focused
widget and the synthesized events are propagated as native key events except
APZ (because keyboard events are synthesized only in the process). This
behavior allows to test including any default action handlers such as
EventStateManager and setting WidgetGUIEvent::mWidget since some C++ handler
checks if it's nullptr.
Differential Revision: https://phabricator.services.mozilla.com/D5516
--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
Currently, TabChild discards eKeyDown and eKeyPress events which are marked as
"repeated" and were dispatched after the latest eKeyDown event comes into the
process. However, keyboard layout utils may generate native key events
as "repeated" even if each native key is important to input proper text.
So, TabChild shouldn't decide if coming keyboard event is skippable only with
mIsRepeat. For solving this issue, this patch adds
mMaybeSkippableInRemoteProcess to WidgetKeyboardEvent and makes
TabChild::SkipRepeatedKeyEvent() check
WidgetKeyboardEvent::CanSkipInRemoteProcess() instead.
On Windows, there are two ways to generate keyboard input messages. One is
using SendMessage() or PostMessage(). The other is SendInput() API. In both
ways, utils can make their input as repeated key messages.
The former case must be safe for this issue since such utils need to set 31st
bit of lParam to 1 explicitly.
On the other hand, in the latter case, the utils probably need to append
KEYEVENTF_KEYUP into KEYBDINPUT::dwFlags. Otherwise, only first call is
treated as non-repeated event.
So, when given message does not came from physical key operation, NativeKey
should set WidgetKeyboardEvent::mMaybeSkippableInRemoteProcess to false
even if WidgetKeyboardEvent::mIsRepeat is true.
MozReview-Commit-ID: 3rinrOjx8Tf
--HG--
extra : rebase_source : 26b6d869260176fc7ef535323b83001bb4b725c2
If a key combination causes text input, we need to dispatch keypress
events without alt/ctrl/meta modifiers since TextEditor won't handle
keyepress events whose altKey, ctrlKey or metaKey is true as inputting
text.
Currently, TextEventDispatcher sets mCharCode of eKeyPress event from
mKeyValue. Then, when altKey, ctrlKey or metaKey is true, it'll call
WillDispatchKeyboardEvent() and then, TextInputHandler needs to reset
the charCode value from native event information.
However, the problem is, TextInputHandler::InsertText() is called
with control character when control key is pressed and InsertText()
clears the modifier information before sending eKeyPress event to
TextEvenDispatcher so that TextEventDispatcher won't call
WillDispatchKeyboardEvent() even though control key is actually
pressed. Therefore, TextInputHandler cannot adjust charCode value
and modifier flags in some cases such as control + option + 'a'.
This patch makes InsertText() stop clearing the modifiers and
makes WillDispatchKeyboardEvent() do it instead. This procedure
is expected by TextEventDispatcher.
MozReview-Commit-ID: Ig6qgRBeQDh
--HG--
extra : rebase_source : 446e8af0e921946f3409d26ede70446248317673
On macOS, option key is mapped to alt key, and it works like AltGr key on
the other platforms. Since our editor doesn't accept keypress events as
typing printable character if one of altKey, ctrlKey and metaKey of the
events is true, widget for macOS sets those attributes to false when an
editor has focus. On the other hand, if no editor has focus, our widget
does not do this hack so that altKey and ctrlKey values of keypress events
are always same as actual user operation and this is same behavior as the
other browsers. Therefore, we need to keep setting altKey of keypress
events to true if no editor has focus but we need to dispatch keypress
events even on content unless the charCode is 0.
So, only on macOS, WidgetKeyboardEvent::IsInputtingText() does not need
to check altKey state.
MozReview-Commit-ID: 4DMgdOfLqvQ
--HG--
extra : rebase_source : 18db91c0d77c6910a206e6c767e6f3b5cfd1c2ab
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
Currently, we dispatch keypress event when Enter is pressed without modifiers
or only with Shift key. However, the other browsers dispatch keypress event
for Ctrl + Enter in any platforms even if it doesn't cause any text input.
So, we should fire keypress event for Ctrl + Enter even in strict keypress
dispatching mode.
Note that with other modifiers, it depends on browser and/or platform.
So, anyway, web developers shouldn't use keypress event to catch
Alt + Enter, Meta + Enter and two or more modifiers + Enter.
MozReview-Commit-ID: 3uUMkhL5VfJ
--HG--
extra : rebase_source : 8149acd958b238c8216f683a42fa05c3cf24570a
Chromium dispatches a keypress event when pressing Enter or Shift+Enter.
Actually, when user press them in <pre> element of HTML editor, ﾂ･n is inserted.
It makes sense to treat the key combinations as inputting text.
MozReview-Commit-ID: Hvx87MZtZkn
--HG--
extra : rebase_source : 196b63843ebcb6e4b398f6b21a4f5f1d020b8db3
UI Events declares that keypress event should be fired when the keypress event
causes some text input. However, we're keeping our traditional behavior for
historical reasons because our internal event handlers (including event
handlers of Thunderbird) handles keypress events for any keys. Therefore,
for minimizing the side effect, we should stop kicking keypress event handlers
in the default event group in web content.
This patch adds new pref for enabling the standard behavior in web content.
Additionally, creates WidgetKeyboardEvent::IsInputtingText() for sharing the
check logic between TextEventDispatcher and TextEditor/HTMLEditor.
MozReview-Commit-ID: 3rtXdLBPeVC
--HG--
extra : rebase_source : 2fc3c9a09840d0d03800c9a42bb83ca76a8db2d5
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.
--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
Extracts out the creation of an NSEvent from a WidgetKeyEvent in
TextInputHandler.mm into generic helper method. The helper is used by headless
to create a fake NSEvent to then build edit commands from key events.
Fixes:
- test_selectevents.html
- test_bug756984.html
- test_movement_by_characters.html
- test_movement_by_words.html
- test_backspace_vs.html
- test_bug1094000.html
- ... many key event tests
MozReview-Commit-ID: 1Jur5MHOrkp
--HG--
extra : rebase_source : fbe320aff8fd2e1b36f3b46e02336e9fc89c48d0
Currently, access key is handled in EventStateManager::PreHandleEvent() with eKeyPress event, i.e., before dispatching it into the DOM tree, if the access key is registered in EventStateManager. So, the main process does not check if the preceding eKeyDown event is consumed in focused remote process.
When preceding eKeyDown event is consumed in the main process, eKeyPress event won't be dispatched by widget. However, if remote process has focus, it's impossible widget to stop dispatching eKeyPress event because preceding eKeyDown event hasn't been handled in the focused remote process yet. Therefore, main process needs to post eKeyPress event to check if preceding eKeyDown event was consumed. When eKeyPress event is marked as "waiting reply from remote process", TabChild sends it back to the main process only when preceding eKeyDown event wasn't consumed. So, only when eKeyPress event is back to the main process, main process should handle accesskey with it.
This patch makes EventStateManager::PreHandleEvent() check if a remote target has focus before handling accesskey. If a remote process has accesskey and there is an accesskey matching with eKeyPress event, it marks the event as "waiting reply from remote content" and stop propagation in the process.
Finally, when eKeyPress event is sent back to TabParent, TabParent::RecvReplyKeyEvent() calls EventStateManager::HandleAccessKey() before dispatching the reply event into the DOM tree.
MozReview-Commit-ID: KsOkakaIVzb
--HG--
extra : rebase_source : 7e0c6966a1bde085e34d45bca4b0166b9fc2f3f1
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
WidgetKeyboardEvent::mInputMethodAppState was used by B2G for managing keyboard event propagation state between chrome process and IME process. Therefore, we can remove it now.
MozReview-Commit-ID: 7BwvzE8VjIR
--HG--
extra : rebase_source : 99e19fee6af0be1de19bd6c23e57e7dbf83a4a9c
Keyboard scrolling works by first dispatching a key event to the focused element
of the page. It is then caught by a XBL binding put on the chrome event handler of
every window. The XBL binding searches through all of its handlers to find one
that can handle the keyboard event. The matching binding has a command string
which is dispatched to the nsGlobalWindowCommands which dispatches to PresShell
which does the actual scrolling.
To do this asynchronously, we need a representation of the XBL handlers that can
be applied to a KeyboardInput to get a KeyboardAction.
This commit adds KeyboardShortcut for this purpose. KeyboardShortcut is designed
to be compatible with nsXBLPrototypeHandler and to only handle the specific cases
we care about for keyboard scrolling. If a XBL handler runs javascript or does
anything else we cannot handle in an OMT situation, then we create a
dispatch-to-content KeyboardShortcut.
MozReview-Commit-ID: 1qzywS3QHVp
--HG--
extra : rebase_source : 8ea4f85c02d04ce5e0fa6e430c44ac920269dd9f
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
UIEvent.isChar is not supported by the other browsers and the value isn't initialized any platforms except on macOS. So, the value isn't useful and we have no reason to keep it.
MozReview-Commit-ID: 4BLpo88gSZj
--HG--
extra : rebase_source : ca950f8cb618a0cadc99ba4c80b5a8df94a20f27
Edgar Chen
Noemi Erli
Simon Giesecke
Masayuki Nakano
Gabriele Svelto
kriswright
Alex Gaynor
Alastor Wu
Sylvestre Ledru
Gijs Kruitbosch
Jeff Gilbert
Andi-Bogdan Postelnicu
Sebastian Hengst
Tristan Bourvon
Boris Zbarsky
Eric Rahm
Brendan Dahl
Ryan Hunt
Ehsan Akhgari
Stephen A Pohl