`input` event listeners may be async functions and may set the text control
element value after the editor ends dispatching an `input` event. Even in this
case, the `input` event listener should not be called recursively by committing
composition which is caused by setting the value because the value is
overwritten by the setting value which was intended by the web app.
Unfortunately, we cannot check whether the value setter is an async `input`
event listener. Therefore, we need to suppress `input` events even after the
editor ends dispatching `input` event.
On the other hand, we should not suppress `input` event if the value is set
by a `compositionupdate` event listener which runs before the editor starts
handling the latest composition change because once we do that, the app won't
receive `input` event for the composition. Therefore, we should not suppress
the editor starts handling the composition change (including during
`beforeinput` event dispatching, but the `beforeinput` is not cancelable, so,
the result will be odd, therefore, we have no tests for the cases).
Therefore, this patch adds a new method to `TextComposition` to make
`TextControlState::SetValue` can check whether the editor is handling the
latest composition change or after that. So, during composition, setting
value should cause `input` events between `TextComposition` starts dispatching a
`compositionupdate` event and `EditorBase` starts handling `eCompositionChange`
event which is dispatched after `compositionupdate`.
Differential Revision: https://phabricator.services.mozilla.com/D214676
Chrome/Android doesn't dispatch composition event when
`InputConnection.commitText` is called from input method without composition.
So we should use same way as compatibility.
Differential Revision: https://phabricator.services.mozilla.com/D210197
I think that we don't need the prefs to disable the behavior because the
behavior conforms to UI Events definition and we've shipped the behavior in
2018. Therefore, nobody shouldn't require to disable the behavior.
Differential Revision: https://phabricator.services.mozilla.com/D177999
Actually, `NativeWeakPtr::Detach` may not release JNI ojbect immediately because
it depends on JNI object's `OnWeakNonIntrusiveDetach`i implementation.
`SessionAccessibility`'s `OnWeakNonIntrusiveDetach` implementation uses the
runnable to run on Android UI thread then disposer runs on main thread, so
if Detach is finished, JNI object isn't detached yet.
If calling `NativeWeakPtrHolder::Attach` immediately with same/recycled Java
object after `NettiveWeakPtr::Detach`, it is possible to run disposer for JNI
object by `OnWeakNonIntrusiveDetach` after Attach is finished. So it may
release newer attached object unfortunately.
So I would like to add a way to waiting for detach JNI object using
`MozPromise`.
Also, `MozPromise.h` includes `Natives.h` header (for `GeckoResult` support).
So I cannot modify inline method to use `MozPromise` due to recursive. So I
split implementation with `NativesInlines.h` as workaround.
Differential Revision: https://phabricator.services.mozilla.com/D175335
HTMLSelectEventListener changes are needed, since currently that code works somewhat by accident given that
mTime often contains totally bogus values, like PR_IntervalNow(). Those changes then reveal issues also in
browser_editAddressDialog.js.
Differential Revision: https://phabricator.services.mozilla.com/D165618
Now, `inputmode` attribute (`inputMode` in the DOM interface) is a global
attribute for `contenteditable`. Therefore, `Input` is not necessary and
`Inputmode` should be `InputMode`.
Differential Revision: https://phabricator.services.mozilla.com/D158244
Now, `inputmode` attribute (`inputMode` in the DOM interface) is a global
attribute for `contenteditable`. Therefore, `Input` is not necessary and
`Inputmode` should be `InputMode`.
Depends on D157894
Differential Revision: https://phabricator.services.mozilla.com/D158244
GeckoView dispatch keyboard event to child process directly and it doesn't
support non-e10s mode. But since about:config will run on chrome process,
GeckoView will dispatch it to parent process.
By bug 1430241, we don't use native key binding when dispatching key event on
parent process. But we forget it for process key event. So even if process key,
we shouldn't use native key binding.
Differential Revision: https://phabricator.services.mozilla.com/D153416
This occurs since newer GBoard's behaviour seems to be changed.
When `GeckoEditable` receives text change from Gecko, it is possible to remove
composing state if composition is started from first character.
If Gecko's text change by IME, we shouldn't reset text state in `onTextChange`.
`mCausedOnlyByComposition` means that this change is by IME.
Differential Revision: https://phabricator.services.mozilla.com/D146159
When using Android with physical keyboard, IME's candidate window is sometimes
misplaced. Some IME/keyboards require insertion marker location to set IME's
candidate window position.
So we should set it from caret rectangle.
Differential Revision: https://phabricator.services.mozilla.com/D141931
`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
Although root cause isn't bug 1713334, this occurs after landing it.
When inputting "." by Swiftkey, it generates key event then dispatches it to
Gecko. After text is changed by this key event, we will update this change
to GeckoView.
But when this occurs, we post invalid selection change to GeckoView, then
`GeckoEditableChild` throws `IllegalArgumentException`.
Normal
======
1. Dispatch "." text change.
2. Receive text and selection change notification by 1.
3. Posted text/selection change notification to GV's parent
This situation
==============
1. Dispatch "." text change.
2. Receive text and selection change notification by 1.
3. Dispatch next "." text change.
4. Posted 2.'s text/selection change notification to GV's parent.
5. `GeckoEditableChild` throws `IllegalArgumentException`.
So when step 4.., we should use 2.'s change data. But since we query current
Gecko's selection data, we may use invalid selection data.
So we should cache selection change, then use it.
Differential Revision: https://phabricator.services.mozilla.com/D124435
When focus isn't changed and inputmode in focused element is changed to none,
we should dismiss software keyboard.
Also, this has same issue for changing from none to text to show software
keyboard.
When changing inputmode, icNotifyIMEContext is called then we should control
software keyboard open/close state too.
Differential Revision: https://phabricator.services.mozilla.com/D122491
When re-focusing input type that has the prompt such as `<input type=week>`,
we show software keyboard unfortunately. We shouldn't show it.
Differential Revision: https://phabricator.services.mozilla.com/D122198
Gecko's text API has a hint whether text change notification is by IME
composing. If by IME composing, it is unnecessary to synchronize it by
onSelectionChange because JavaScript doesn't block/change inputted text.
It means that shadow (Java) text is always matched to Gecko text.
So we don't have to synchronize shadow text during composing.
Differential Revision: https://phabricator.services.mozilla.com/D116476
deleteSurroundingText may create multiple text transactions. This test
failure occurs when multiple text transactions are dispatched to Gecko.
GeckoEditableSupport records text changes by Gecko then it notifies Java
of text changes. And it merges old text changes with new text changes by
AddIMETextChange to reduce JNI/Binder calls if possible.
This issue is that AddIMETextChange creates incorrect text change range
by merging text change ranges.
Actually, TextChangeData already has merge function now, so we should use it
instead of own merge function in GeckoEditableSupport.
Differential Revision: https://phabricator.services.mozilla.com/D111207
Actually, before starting composition, we always remove current selected
text. So it causes that input event is fired by this operation. This is
different of Blink.
`TextEventDispatcher` can set composition string using selected text when
starting composition. So we can reduce this input event.
Also, I mistake bug 1499076 fix. By this fix, we always fires input event
when having selected text even if it is unnecessary. This changeset has
this fix too.
Differential Revision: https://phabricator.services.mozilla.com/D105464
This is a regression by bug 1651705.
After landing it, we use read-write lock to access GeckoEditableChild object.
But when using form submission with target=_blank, since we use some nested
event loop to open new window in same process, we may try to dispose
GeckoEditableChild even if it is still used. Then, it may be dead lock.
So I add a blocker class helper not to dispose GeckoEditableChild immediately.
Differential Revision: https://phabricator.services.mozilla.com/D103742
Before deleting `IMEState::Enabled::PLUGIN`, let's make it an enum class
for making the change safer. Almost all of this change is done by
"replace" of VSCode.
Differential Revision: https://phabricator.services.mozilla.com/D100100
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
When debugging text issue on GV, I sometimes enable `DEBUG_ANDROID_IME` to
output log. But I think that it is better to use `MOZ_LOG` since we can get
the log on Fenix build.
If using GVE, we can output log via the following command.
```
adb shell am start -n org.mozilla.geckoview_example/.GeckoViewActivity --es env0 "MOZ_LOG=GeckoEditableSupport:5"
```
But this change is Nightly only due to footprint etc at first.
Differential Revision: https://phabricator.services.mozilla.com/D92449
`android.view.inputmethod.EditorInfo` has `inputType` feild that can control
capitalize of software keyboard. GeckoView should use it for autocapitalize
attribute support.
Differential Revision: https://phabricator.services.mozilla.com/D86678
This patch is similar to part 4 but for `GeckoEditableSupport`.
Conversions over to `NativeWeakPtr` are pretty straight forward thanks to the
type system. Basically we take a `NativeWeakPtr`, call `Access()` on it, and
if the accessor is truthy, then we call whatever methods we need to call.
Creation of new pointers is done using `NativeWeakPtrHolder::Attach()` and
detaching of strong references is done by `NativeWeakPtr::Detach()`.
Differential Revision: https://phabricator.services.mozilla.com/D87364
This patch is similar to part 4 but for `GeckoEditableSupport`.
Conversions over to `NativeWeakPtr` are pretty straight forward thanks to the
type system. Basically we take a `NativeWeakPtr`, call `Access()` on it, and
if the accessor is truthy, then we call whatever methods we need to call.
Creation of new pointers is done using `NativeWeakPtrHolder::Attach()` and
detaching of strong references is done by `NativeWeakPtr::Detach()`.
Differential Revision: https://phabricator.services.mozilla.com/D87364
This patch is similar to part 4 but for `GeckoEditableSupport`.
Conversions over to `NativeWeakPtr` are pretty straight forward thanks to the
type system. Basically we take a `NativeWeakPtr`, call `Access()` on it, and
if the accessor is truthy, then we call whatever methods we need to call.
Creation of new pointers is done using `NativeWeakPtrHolder::Attach()` and
detaching of strong references is done by `NativeWeakPtr::Detach()`.
Differential Revision: https://phabricator.services.mozilla.com/D87364
This is timing issue to set `InputContext` that is used by setting keyboard
layout.
`InputContext` is set by chrome process only. Since we want to use it on
child process, we store cached value by `NOTIFY_IME_OF_FOCUS`. But before
setting it, we may use old cached value unfortunately.
So we have to wait until valid cached `InputContext` is set.
Also, I add some assertions for this check.
Differential Revision: https://phabricator.services.mozilla.com/D85821
This is timing issue when using iFLYTEC keyboard in Xiaomi App Store.
Although replace text transaction often dispatch dummy text change, it may be
unnecessary when other text change is already in text change queue. This issue
occurs if dummy text change is dispatched in the queue and other text change
is also dispatched in the queue.
`AddIMETextChange` merges old text change with newer text change when its range
is overlapped, but it doesn't consider range is same. So if same range, we
should adjust old end simply.
GV-junit test case emulates this situation, but since this is timing issue,
we won't reproduce this by this test case. But it is useful to check future
regressions.
Differential Revision: https://phabricator.services.mozilla.com/D84140
If client script wants to commit composition string per input, it sometimes
use the following script.
```
let input = document.getElementById('input');
input.addEventListener('input', () => {
input.blur();
input.focus();
});
```
Since `blur` will commit composition string, this script can commit text. But
since Gecko has an optimization for this situation, focus won't be lost
completely.
Although GeckoView synchronizes Java text and selection with Gecko text when
getting focus, this sample may be failed due to timing issue. `blur` tries to
commit string, but result is never returned since focus is lost as temporary
(although text is finally committed in Gecko.). Then, GeckoView are waiting
for result that is never returned forever, So this synchronization is failed.
When getting focus again, we should synchronize it at force.
Differential Revision: https://phabricator.services.mozilla.com/D80147
Most IMEs handle arrow key, then set caret position by IME. But GBoard doesn't
handle it. GBoard will dispatch key event to application for arrow left/right
even if having IME composition.
Since Gecko doesn't dispatch key press during IME composition due to DOM UI
events spec, we have to emulate arrow key's behaviour.
And, `GeckoEditable` has a hack that composition text is committed when
dispatching key event. This hack is unnecessary after landing
bug 1613804 that `InputConnection.finishComposingText` is implemented.
Differential Revision: https://phabricator.services.mozilla.com/D76658
When calling `InputConnection.finishComposingText` commits composition string,
but caret position isn't changed. But
`RemoveComposition(COMMIT_IME_COMPOSITION)` sets caret position to end of
string.
So we have to restore caret position after calling
`RemoveComposition(COMMIT_IME_COMPOSITION)` via `finishComposingText`.
Differential Revision: https://phabricator.services.mozilla.com/D76657
Most IMEs handle arrow key, then set caret position by IME. But GBoard doesn't
handle it. GBoard will dispatch key event to application for arrow left/right
even if having IME composition.
Since Gecko doesn't dispatch key press during IME composition due to DOM UI
events spec, we have to emulate arrow key's behaviour.
And, `GeckoEditable` has a hack that composition text is committed when
dispatching key event. This hack is unnecessary after landing
bug 1613804 that `InputConnection.finishComposingText` is implemented.
Differential Revision: https://phabricator.services.mozilla.com/D76658
When calling `InputConnection.finishComposingText` commits composition string,
but caret position isn't changed. But
`RemoveComposition(COMMIT_IME_COMPOSITION)` sets caret position to end of
string.
So we have to restore caret position after calling
`RemoveComposition(COMMIT_IME_COMPOSITION)` via `finishComposingText`.
Differential Revision: https://phabricator.services.mozilla.com/D76657
If key down event handler calls `event.preventDefault()`, web browser
shouldn't fire key press event. But GeckoView may fire key press
unfortunately if using software keyboard.
So we don't fire key press event when dispatching `eKeyDown` returns
`nsEventStatus_eConsumeNoDefault`.
Differential Revision: https://phabricator.services.mozilla.com/D75981
Actually we emulate key event (down, press and up) from replace transaction of
`Editable`. When dispatching key press, we always update current caret position.
Most situations is the following.
1. Dispatch keypress
2. Dispatch another keypress
3. Receive merged text/selection change result by 1. and 2.
4. Sync shadow (Java's Editable) text with 3.'s result. It means selection is
correct position now.
5. Dispatch keypress with correct position.
When this issue occurs, the following situation occurs.
1. Dispatch keypress
2. Dispatch another keypress
3. Receive text/selection change result of 1.
4. Sync shadow (Java's Editable) text with 3.'s result. It means selection is
old position now.
5. Dispatch another keypress with old position.
6. Receive text/selection change result of 2.
7. Receive text/selection change result of 5.
So when dispatching key press, we shouldn't always update selection if unnecessary.
Because selection range is already often set before dispatching key press.
Differential Revision: https://phabricator.services.mozilla.com/D71179
`inputmode=none` has to close software keyboard. `inputmode` value is lower
case except to `mozAwesomebar` by bug 1618763, so we don't have to use
`equalsIgnoreCase` for `inputmode`.
Differential Revision: https://phabricator.services.mozilla.com/D67459
Gecko don't commit composition when software keyboard calls
InputConnection.finishComposingText. It is incompatible with Blink's behaviour.
BaseInputConnection.finishComposingText() implementation is the following.
1. Begin batch edit.
2. Remove all composition span flag.
3. End batch edit.
So if no composition after batch edit is finished, we should commit it on Gecko
to synchronize composition state.
Differential Revision: https://phabricator.services.mozilla.com/D66370
When deleting text by backspace key of VKB, VKB might use `InputConnection.setComposingText`, not using KeyEvent. So although we dispatch dummy key event, the order of events is incorrect. We should dispatch keydown before input event.
Differential Revision: https://phabricator.services.mozilla.com/D64892
Masayuki Nakano