The method may call a callback. It's designed never to run script, but
technically possible. Therefore, it should be marked as
`MOZ_CAN_RUN_SCRIPT` for the safety in the future.
Differential Revision: https://phabricator.services.mozilla.com/D290334
We should use `ContiguousEnumSerializerInclusive` to receive/send an
`enum` value.
`IMENotificationRequests` has an enum whose values are used as bit
field. So, we can use `EnumSet` for it and then, we don't need to write
`ParamTraits` for it directly.
Differential Revision: https://phabricator.services.mozilla.com/D285200
Most changes are automated. Relevant bit is dom/.clang-format. I had to
manually disable clang-format in a few places where importing external
files and so on that aren't self-contained, and fix a couple includes /
forward declarations.
Differential Revision: https://phabricator.services.mozilla.com/D256800
The builtin legacy IME of Windows to type a Unicode with typing a code point
causes consumed `eKeyDown` events while typing the code point, i.e., without
`eKeyPress` (FYI: The consumed state is not exposed to the web, it's used only
in chrome UI for the compatibility with Chrome). Then, `BrowserChild` store
whether the last `eKeyDown` was consumed or not to prevent the following
`eKeyPress`. Finally, a `eKeyPress` event is fired to input the Unicode
character after `eKeyUp` for `Alt`. The stored value is set to new value only
when another `eKeyDown` event is sent from the parent process. Therefore,
the last digit inputting `eKeyDown` causes `BrowserChild` thinking the last
`eKeyDown` is consumed so that the last `eKeyPress` is not dispatched.
This patch makes `BrowserChild` to store the `code` value of the last consumed
`eKeyDown` and check the `code` value to consider whether coming `eKeyPress`
should be or not be dispatched to `PresShell` and the DOM.
Differential Revision: https://phabricator.services.mozilla.com/D207957
The builtin legacy IME of Windows to type a Unicode with typing a code point
causes consumed `eKeyDown` events while typing the code point, i.e., without
`eKeyPress` (FYI: The consumed state is not exposed to the web, it's used only
in chrome UI for the compatibility with Chrome). Then, `BrowserChild` store
whether the last `eKeyDown` was consumed or not to prevent the following
`eKeyPress`. Finally, a `eKeyPress` event is fired to input the Unicode
character after `eKeyUp` for `Alt`. The stored value is set to new value only
when another `eKeyDown` event is sent from the parent process. Therefore,
the last digit inputting `eKeyDown` causes `BrowserChild` thinking the last
`eKeyDown` is consumed so that the last `eKeyPress` is not dispatched.
This patch makes `BrowserChild` to store the `code` value of the last consumed
`eKeyDown` and check the `code` value to consider whether coming `eKeyPress`
should be or not be dispatched to `PresShell` and the DOM.
Differential Revision: https://phabricator.services.mozilla.com/D207957
The preference "test.events.async.enabled" controls the usage of
widget events in general, but Marionette doesn't support all of
them yet. To get widget events enabled for web-platform tests
those unsupported event types need to still synthesize the event.
Differential Revision: https://phabricator.services.mozilla.com/D188296
The preference "test.events.async.enabled" controls the usage of
widget events in general, but Marionette doesn't support all of
them yet. To get widget events enabled for web-platform tests
those unsupported event types need to still synthesize the event.
Differential Revision: https://phabricator.services.mozilla.com/D188296
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
Unfortunately, it cannot has `Maybe` because of used by a union. Therefore,
it needs to manage with `bool` members of whether it's initialized with or
without error and whether it has a range.
Note that this changes `nsITextInputProcessorCallback.idl` which is currently
only for automated tests too. The new behavior will be tested by the last
patch in this bug.
Differential Revision: https://phabricator.services.mozilla.com/D137424
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
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
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
That includes changing privacy.resistFingerprinting to a non-VarCache pref,
because it doesn't need to be a VarCache.
Differential Revision: https://phabricator.services.mozilla.com/D36162
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
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
This implement a helper API to guess keyCode value of a printable key with
assuming active keyboard layout is US-English. The reason why this stops
computing key value from key value is, most users of such API probably want
to emulate input from US-English keyboard layout if they don't specify the
detail. Therefore, the new API simply maps each ASCII character to a
DOM keyCode which is usually mapped in US-English keyboard layout.
Differential Revision: https://phabricator.services.mozilla.com/D5515
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
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
For testing IMEContentObserver, text change, selection change and position change notifications should be exposed to JS with nsITextInputProcessorNotification.
MozReview-Commit-ID: 3PUhKXRwnAn
Bug 1343075 - 1a. Add TextEventDispatcherListener::GetIMEUpdatePreference; r=masayuki
Add a GetIMEUpdatePreference method to TextEventDispatcherListener to
optionally control which IME notifications are received by NotifyIME.
This patch also makes nsBaseWidget forward its GetIMEUpdatePreference
call to the widget's native TextEventDispatcherListener.
Bug 1343075 - 1b. Implement GetIMEUpdatePreference for all TextEventDispatcherListener; r=masayuki
This patch implements GetIMEUpdatePreference for all
TextEventDispatcherListener implementations, by moving previous
implementations of nsIWidget::GetIMEUpdatePreference.
Bug 1343075 - 2. Allow setting a PuppetWidget's native TextEventDispatcherListener; r=masayuki
In PuppetWidget, add getter and setter for the widget's native
TextEventDispatcherListener. This allows overriding of PuppetWidget's
default IME handling. For example, on Android, the PuppetWidget's native
TextEventDispatcherListener will communicate directly with Java IME code
in the main process.
Bug 1343075 - 3. Add AIDL interface for main process; r=rbarker
Add AIDL definition and implementation for an interface for the main
process that child processes can access.
Bug 1343075 - 4. Set Gecko thread JNIEnv for child process; r=snorp
Add a JNIEnv* parameter to XRE_SetAndroidChildFds, which is used to set
the Gecko thread JNIEnv for child processes. XRE_SetAndroidChildFds is
the only Android-specific entry point for child processes, so I think
it's the most logical place to initialize JNI.
Bug 1343075 - 5. Support multiple remote GeckoEditableChild; r=esawin
Support remote GeckoEditableChild instances that are created in the
content processes and connect to the parent process GeckoEditableParent
through binders.
Support having multiple GeckoEditableChild instances in GeckoEditable by
keeping track of which child is currently focused, and only allow
calls to/from the focused child by using access tokens.
Bug 1343075 - 6. Add method to get GeckoEditableParent instance; r=esawin
Add IProcessManager.getEditableParent, which a content process can call
to get the GeckoEditableParent instance that corresponds to a given
content process tab, from the main process.
Bug 1343075 - 7. Support GeckoEditableSupport in content processes; r=esawin
Support creating and running GeckoEditableSupport attached to a
PuppetWidget in content processes.
Because we don't know PuppetWidget's lifetime as well as nsWindow's,
when attached to PuppetWidget, we need to attach/detach our native
object on focus/blur, respectively.
Bug 1343075 - 8. Connect GeckoEditableSupport on PuppetWidget creation; r=esawin
Listen to the "tab-child-created" notification and attach our content
process GeckoEditableSupport to the new PuppetWidget.
Bug 1343075 - 9. Update auto-generated bindings; r=me
For making our code clearer by the stronger type check, we should change the anonymous enum for NS_TEXTRANGE_* to enum class whose name is "TextRangeType" and whose type is "RawTextRangeType" which is an alias of uint8_t.
Additionally, this also adds some utility methods for them.
Note that some lines which are changed by this patch become over 80 characters but it will be fixed by the following patches.
MozReview-Commit-ID: 76izA1WqTkp
Masayuki Nakano