This patch does not make some header files stop including the inline
header because fixing them require more changes.
Note that `#include "nsComponentManagerUtils.h"` is fixing a bustage
caused by "use of undeclared identifier 'do_CreateInstance'" error.
Differential Revision: https://phabricator.services.mozilla.com/D304432
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
widget/android/GeckoEditableSupport.cpp:653:21: error: implicit capture of 'this' with a capture default of '=' is deprecated [-Werror,-Wdeprecated-this-capture]
widget/android/GeckoEditableSupport.cpp:748:7: error: implicit capture of 'this' with a capture default of '=' is deprecated [-Werror,-Wdeprecated-this-capture]
Differential Revision: https://phabricator.services.mozilla.com/D281491
`PuppetWidget` in child process and `nsWindow` in parent process have a binder
session to communicate IME.
When DOM document is created, we attach `GeckoEditable` that is both
parent process and child process. But If child document in iframe is created,
we also re-attach both. Then, when re-attaching `GeckoEditable`, we also
reset IME to synchronize Gecko's text.
It is unnecessary to re-attach `GeckoEditable` if child's `PupeetWidget` has
attached `GeckoEditble`. Because parent's `GeckoEdiable` is always same,
and it is associated with `GeckoSession`.
So we should avoid to re-attach `GeckoEditable`.
Differential Revision: https://phabricator.services.mozilla.com/D271397
To debug and report bugs, I would like to add a logging support for
input things on GeckoView. `"IMEHnadler"` is common name for logging
IME code on all platforms.
This is Nightly only. So no effect on release and beta.
Differential Revision: https://phabricator.services.mozilla.com/D269354
To debug and report bugs, I would like to add a logging support for
input things on GeckoView. `"IMEHnadler"` is common name for logging
IME code on all platforms.
This is Nightly only. So no effect on release and beta.
Differential Revision: https://phabricator.services.mozilla.com/D269354
Originally, media keys were dispatched to `AudioManager` if web content
doesn’t consume it by bug 730192. But after GeckoView (moving to e10s),
we always call `GeckoEditable.onDefaultKeyEvent()` if focused element
isn't editable even if web content consumes it.
`DispatchKeyboardEvent` is asynchronous and it doesn't wait for
whether the event is consumed or not. Also, even if we set the flag for
"waiting reply from remote process", its flag will reset in
`DispatchKeyboardEventInternal`.
So I would like to inhibit this. Then if media key, we set the flag if
on parent process.
Differential Revision: https://phabricator.services.mozilla.com/D256739
We avoid to reset `InputConnection` not to erase IME's composing text
for some situations such as `element.focus()` call.
When changing inputmdoe during user interaction, we should reset
`InputConnection` to change keyboard layout.
Also, I add an API to emulate user interaction to write a test for
this issue.
Differential Revision: https://phabricator.services.mozilla.com/D240563
`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
Masayuki Nakano