`GlobalKeyListener` try to match shortcut keys with exactly checking `Shift`
state, but for the cases which do not match localized language and active
keyboard layout location, it scans another shortcut keys with ignoring
`Shift` state if no handler is available.
`<command>` elements and `<key>` elements may be disabled conditionally.
E.g., Zoom-in/Zoom-out are disabled when current zoom level is max/min value.
In this case, it's odd that another shortcut key which does not exactly match
the modifiers works.
Therefore, this patch makes `GlobalKeyListener` does not try to scan handlers
with ignoring `Shift` state if it has already found a disabled handler which
exactly matches with the modifiers.
Differential Revision: https://phabricator.services.mozilla.com/D184789
We've already known that `WidgetQueryContentEvent` is dispatched at initializing
a popup menu on macOS (bug 1530188). Therefore, I made the dispatcher under
`widget/cocoa` set `WidgetQueryContentEvent::mNeedLayoutFlush` to `false` to
avoid to flush pending things in `ContentEventHandler`, but
`PresShell::EventHandler` does it.
Differential Revision: https://phabricator.services.mozilla.com/D185264
When we implement `KeyboardEvent.key`, its value for Windows Logo key was
declared as `OS`, but now the spec declares it as `Meta`.
When we implement `KeyboardEvent.code`, its value for Windows Logo keys in
Win/Linux and Command keys in macOS are declared as `OSLeft`/`OSRight`, but
now the spec declares them as `MetaLeft`/`MetaRight`.
This patch remaps and renames them.
Differential Revision: https://phabricator.services.mozilla.com/D183481
When we implement `KeyboardEvent.key`, its value for Windows Logo key was
declared as `OS`, but now the spec declares it as `Meta`.
When we implement `KeyboardEvent.code`, its value for Windows Logo keys in
Win/Linux and Command keys in macOS are declared as `OSLeft`/`OSRight`, but
now the spec declares them as `MetaLeft`/`MetaRight`.
This patch remaps and renames them.
Differential Revision: https://phabricator.services.mozilla.com/D183481
For handling (ignoring) "too late" composition commit request from content
process, we need to distinguish a request is for which composition. Therefore,
we need to number each composition originated in the parent process.
This patch makes `TextComposition` instance which is created at first
composition event for a composition consider a composition ID in the parent
process and set it to composition events which are dispatched into the DOM
tree in the parent or sent to a remote process.
And also this patch adds the composition ID param to the request method of
committing composition and reply methods to notify the parent process of ending
a composition event handling.
The last patch handle them in `ContentCacheInParent` to consider
whether a request/reply should be ignored or handled.
Differential Revision: https://phabricator.services.mozilla.com/D179310
For handling (ignoring) "too late" composition commit request from content
process, we need to distinguish a request is for which composition. Therefore,
we need to number each composition originated in the parent process.
This patch makes `TextComposition` instance which is created at first
composition event for a composition consider a composition ID in the parent
process and set it to composition events which are dispatched into the DOM
tree in the parent or sent to a remote process.
And also this patch adds the composition ID param to the request method of
committing composition and reply methods to notify the parent process of ending
a composition event handling.
The last patch handle them in `ContentCacheInParent` to consider
whether a request/reply should be ignored or handled.
Differential Revision: https://phabricator.services.mozilla.com/D179310
It's designed for caching content information of focused editor. However, at
sending focus notification to the main process, the editor may have already
been blurred but `IMEContentObserver` may have not known it yet. In this edge
case, only query selection succeeds since IMEContentObserver still has a cache,
but query the others failed because of root content node check of
`IMEContentObserver::HandleQueryContentEvent`. If a content process meets this
case, it should not send focus notification and stop storing the content since
IME shouldn't get focus nor query non-editable content.
On the other hand, the reported testcase reproduces this with a fuzzing API
called **in** the content process. Therefore, I have no idea how to reproduce
it without the API. That's the reason why this patch does not contain new tests.
Differential Revision: https://phabricator.services.mozilla.com/D141821
Querying selection for getting writing mode may run script in the main process
if focus is in it. For avoiding new users of writing mode at selection **only**
when the value is required during an editable content has focus,
`TextEventDispatcher` should always store writing mode at receiving focus
notification.
Differential Revision: https://phabricator.services.mozilla.com/D138008
I'd like to use it in `IMEData.h`. However, adding new include into it may
cause bustage with MinGW, and it's included by `nsIWidget.h` because `nsIWidget`
requires some classes defined in `IMEData.h`. Therefore, I'd like to make a
new header file for avoiding the include hell.
Differential Revision: https://phabricator.services.mozilla.com/D138007
Finally, making `WidgetQueryContentEvent::Succeeded` return `true` when there
is no selection when its message is `eQuerySelectedText`, and making
`ContentEventHandler::OnQuerySelectedText` set the no selection range data even
when the queried selection type is "normal. Then, all things which are
changed by the previous patches start to work.
And this patch adds a simple test for `ContentCache` and update tests of
`nsITextInputProcessor`.
Differential Revision: https://phabricator.services.mozilla.com/D137432
`StartOffset` and `EndOffset` of `IMENotification::SelectionChangeDataBase`
depend on whether the range is reversed or not. Therefore, their actual
meaning is "anchor offset" and "focus offset" in the DOM selection terms.
Similarly, `SelectionStartOffset` and `SelectionEndOffset` of
`WidgetQueryContentEvent::Reply` are exactly same ones.
Therefore, they should be renamed to `AnchorOffset` and `FocusOffset` for
making what they return clearer.
Differential Revision: https://phabricator.services.mozilla.com/D137427
It's intended to indicate whether the selection is collapsed or not, but it can
be referred by other members, there is no reasonable user and the name makes
developers confused.
Differential Revision: https://phabricator.services.mozilla.com/D137422
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
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
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
Sorry for this big patch.
This makes `WidgetQueryContentEvent::Reply` is stored with `Maybe` to get
rid of `WidgetQueryContentEvent`. And `Reply` stores offset and string
with `Maybe` and ``OffsetAndData<uint32_t>`, and also tentative caret offset
with `Maybe`. Then, we can get rid of `WidgetQueryContentEvent::NOT_FOUND`.
Note that I tried to make `OffsetAndData` have a method to create `NSRange`
for cocoa widget. However, it causes the column limit`to 100 or longer
and that causes unrelated changes in `TextEvents.h` and `IMEData.h`.
Therefore, I create an inline function in `TextInputHandler.mm` instead.
Differential Revision: https://phabricator.services.mozilla.com/D98264
Currently, it validates the result of `mStart + aInsertPointOffset` with
the following code.
```
CheckedInt<uint32_t> absOffset =
CheckedInt<uint32_t>(mOffset) + aInsertionPointOffset;
```
However, this does not work when `mOffset` is a negative value since it's
converted to unsigned value before adding `aInsertionPointOffset`.
Therefore, when TSF queries first character rect of the document with
`TSFTextStore::GetTextExt()` whose `acpStart` is set to 0, and composition
start is second or later character, the check may fail and anyway, even
if it does not overflow, the computed offset becomes too big and fails
to query character rect anyway.
Therefore, this patch makes its constructor take computed value instead.
Unfortunately, this cannot be tested without writing a big framework to
test async composition event handling because synthesizing similar
query text rect in same process works fine.
Differential Revision: https://phabricator.services.mozilla.com/D97269
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
Olli Pettay
Masayuki Nakano
Cristian Tuns
Cosmin Sabou
Emilio Cobos Álvarez
Narcis Beleuzu
Butkovits Atila
Brad Werth
Simon Giesecke
Edgar Chen
Noemi Erli
Gabriele Svelto
kriswright
Alex Gaynor
Alastor Wu