Even if `element.focus` is called from chrome, we always open virtual keyboard.
But I would like to change this behaviour that virtual keyboard isn't opened
via `element.focus` that is chrome script.
Depends on D44104
Differential Revision: https://phabricator.services.mozilla.com/D44105
--HG--
extra : moz-landing-system : lando
I would like to log `IMEState` and `InputContextAction`in widget. But this
utilities are in `IMEStateManager`, so I would like to move it to widget
by using `mozilla/ToString.h`.
Differential Revision: https://phabricator.services.mozilla.com/D44103
--HG--
extra : moz-landing-system : lando
Converts intl.ime.hack.on_any_apps.fire_key_events_for_composition to a static pref and updates its usages.
Differential Revision: https://phabricator.services.mozilla.com/D42393
--HG--
extra : moz-landing-system : lando
When long tapping on input element, the behavior of virtual keyboard is different of Chrome. Firefox opens virtual keyboard, but Chrome doesn't.
So I would like to change to same behavior of Chrome.
Also, after this fix, action bar (copy, paste and etc) won't be disappeared immediately after it appears by long tap. Before applying this fix, virtual keyboard is shown, then focused element is scrolled to center. So action bar may be disappeared. But after applying this fix, focused element isn't scrolled. So action bar keeps same position.
Depends on D35991
Differential Revision: https://phabricator.services.mozilla.com/D35992
--HG--
extra : moz-landing-system : lando
To avoid FlushIMEChanges per updating IME composition, we calculate composition count in DoReplaceText. But when using GV+e10s, this calculation is sometimes invalid since NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED event isn't received per PendingComposition. Because, IMEStateManager will merge this completed events due to optimization of IME event.
Also, DoUpdateComposition calls SetPendingComposition, but it doesn't touch mIMEActiveCompositionCount,
So when using some IME, this value is minus or forever non-zero on some IMEs.
So we shouldn't use atomic count. When receiving NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED, we should reset it and allow IMEFlushChanges since Gecko has already handled all IME composition events in event queues.
Differential Revision: https://phabricator.services.mozilla.com/D14668
--HG--
extra : moz-landing-system : lando
To avoid FlushIMEChanges per updating IME composition, we calculate composition count in DoReplaceText. But when using GV+e10s, this calculation is sometimes invalid since NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED event isn't received per PendingComposition. Because, IMEStateManager will merge this completed events due to optimization of IME event.
Also, DoUpdateComposition calls SetPendingComposition, but it doesn't touch mIMEActiveCompositionCount,
So when using some IME, this value is minus or forever non-zero on some IMEs.
So we shouldn't use atomic count. When receiving NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED, we should reset it and allow IMEFlushChanges since Gecko has already handled all IME composition events in event queues.
Differential Revision: https://phabricator.services.mozilla.com/D14668
--HG--
extra : moz-landing-system : lando
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
Make some fixes in GeckoEditable and GeckoEditableSupport to make the
new tests pass under e10s.
Differential Revision: https://phabricator.services.mozilla.com/D11989
--HG--
extra : moz-landing-system : lando
Sometimes, when recovering from an IME error, we get selection offsets
that are out of bounds. Limit the offsets in that case so we don't
crash.
Differential Revision: https://phabricator.services.mozilla.com/D11990
--HG--
extra : moz-landing-system : lando
If we already queued some synchronize replies, we should queue any
additional replies so that we don't prematurely reply to an event that
has not finished processing yet.
Also add delay for synchronize replies when a `OnImeUpdateComposition`
call is being processed.
Differential Revision: https://phabricator.services.mozilla.com/D9850
Currently we make a sync call from the child process to the parent
process to retrieve the IGeckoEditableParent instance. However, that can
lead to deadlocks when a11y code makes parent-to-child async calls at
the same time. This patch makes the call async to avoid the deadlock.
Differential Revision: https://phabricator.services.mozilla.com/D10663
During a session transfer, update existing GeckoEditableChild instances
in the parent and child processes to use the new GeckoEditableParent
instance that corresponds to the new session. If the GeckoEditableChild
has focus, take additional steps to make sure the GeckoEditableParent
receives current input context and focus information.
Differential Revision: https://phabricator.services.mozilla.com/D8996
Make LayerViewSupport, NPZCSupport, GeckoEditableSupport, and
SessionAccessibility use the new disposal mechanism to ensure the
disposal is performed safely.
Differential Revision: https://phabricator.services.mozilla.com/D7110
--HG--
extra : moz-landing-system : lando
Check for null TextComposition pointer, which can apparently happen
during regular usage.
MozReview-Commit-ID: 6nKjyBVL2vF
--HG--
extra : rebase_source : 68d8ff37612f6908b3983993fc73d19e9c0b0e50
Currently, we expect editing operations in
GeckoEditableSupport::OnImeReplaceText to cause synchronous text change
notifications. However, under e10s, text change notifications can be
asynchornous. The new code keeps track of active OnImeReplaceText calls,
and look for async text changes before replying to the calls.
MozReview-Commit-ID: INM3JLmQebK
--HG--
extra : rebase_source : ff5b728ef437fcd78e4e7eced9c9a537d4698dce
Right now we coalesce notifyIMEContext calls but only for legacy
reasons. With the current code we don't want to coalesce calls, in order
to be properly notified of blurring and focusing.
MozReview-Commit-ID: 6N2jhyyBKui
--HG--
extra : rebase_source : 0a488a726b834da4f6124092426638f4be368d43
Right now we always notify Java of input blur. However, when input is
rapidly blurred and then focused again, we don't want to generate the
unnecessary blur notification, in order to avoid unwanted effects such
as the keyboard flashing.
MozReview-Commit-ID: AL6aLAHqNpD
--HG--
extra : rebase_source : c0a6a731f95f997a7a8e19eacdb635f99d21ebf5
When EditorEventListener receives keyboard events, it tries to execute
native key bindings which are stored by each keyboard event. For performance
reason in e10s, TabParent initializes native key binding information of every
keyboard event before sending it to the remote process. Therefore,
PuppetWidget checks if every keyboard event has native key binding information.
However, the native key binding information of dummy keyboard events marked as
"processed by IME" on Android are never initialized before sending PuppetWidget.
Therefore, we hit MOZ_ASSERT in PuppetWidget.
This patch makes GeckoEditableSuppor::SendIMEDummyKeyEvent() set native key
binding information to "none" before dispatching every keyboard event since
keyboard events during composition shouldn't cause any edit actions.
MozReview-Commit-ID: Bk532ahCQP6
--HG--
extra : rebase_source : 939c1befd4b587681192b6827e7c7fa52619d498
On Android, GeckoEditableSupport has already dispatched eKeyDown event and
eKeyUp event even during composition. I.e., the pref which will be enabled
by bug 354358 has already been set to true only on Android.
On the other hand, GeckoEditableSupport does not dispatch them if content
listens to "input", "compositionstart", "compositionupdate" or
"compositionend". So, different from the other platforms, we need additional
pref to make the new behavior behind pref.
Therefore, this patch adds a new pref,
"intl.ime.hack.on_any_apps.fire_key_events_for_composition", to override
existing "intl.ime.hack.on_ime_unaware_apps.fire_key_events_for_composition"
pref. And sets mKeyCode and mKeyNameIndex of the dummy KeyboardEvents to
NS_VK_PROCESSKEY and KEY_NAME_INDEX_Process.
MozReview-Commit-ID: Fuy0Ir2xiO5
--HG--
extra : rebase_source : c76b613ea186458ebdf0d67f4bc984e8ac5f1041
On Android, GeckoEditableSupport has already dispatched eKeyDown event and
eKeyUp event even during composition. I.e., the pref which will be enabled
by bug 354358 has already been set to true only on Android.
On the other hand, GeckoEditableSupport does not dispatch them if content
listens to "input", "compositionstart", "compositionupdate" or
"compositionend". So, different from the other platforms, we cannot test
this behind pref ("dom.keyboardevent.dispatch_during_composition") even in
Nightly.
Therefore, this patch enables new behavior only when it's Nightly build or
early Beta. And sets mKeyCode and mKeyNameIndex of the dummy KeyboardEvents
to NS_VK_PROCESSKEY and KEY_NAME_INDEX_Process.
MozReview-Commit-ID: Fuy0Ir2xiO5
--HG--
extra : rebase_source : fade31954eaa1be8b7592977095ba8aebdd75104
The unified headers already define the keycodes in
GeckoEditableSupport.cpp, so only define them ourselves when not using
unified headers (by checking the __ANDROID_API_X__ macros).
MozReview-Commit-ID: 3Ptakcm0rW
--HG--
extra : rebase_source : c7baf2fc9c02cc891946a197fb17309d3593a610
The unified headers already define the keycodes in
GeckoEditableSupport.cpp, so only define them ourselves when not using
unified headers (by checking the __ANDROID_API_X__ macros).
MozReview-Commit-ID: 3Ptakcm0rW
--HG--
extra : rebase_source : 01c302fa92ea00374d8f1dae326670dd98ad3ec8
Call PreventNativeKeyBindings() for all key events to prevent triggering
an assertion in PuppetWidget.
MozReview-Commit-ID: 3x96p9baTze
--HG--
extra : rebase_source : 1f1477074e49ca7be9b3f3956289adf4f288a223
Move GeckoEditableClient and GeckoEditableListener to inside
TextInputController, next to TextInputController.Delegate. This
consolidates the three internal interfaces used for IME in one place.
The patch also changes the last notifyIMEContext parameter to an int
flag to indicate private browsing or user action. This allows for future
expansion without adding more parameters to notifyIMEContext.
MozReview-Commit-ID: BjscdNr9TkO
--HG--
extra : rebase_source : 87166a55e5978eda4a7c3065db9b68658e33af35
Remove InputConnectionListener, which was replaced by
TextInputController.Delegate, and remove IME_STATE_PLUGIN, which is not
used anymore.
MozReview-Commit-ID: GCbJXWNCmTk
--HG--
extra : rebase_source : c90bc79585ce4c5b9c0de5e07b0ea52531b65e04
Use the LayerSession coordinates APIs instead of manually calculating
coordinates using viewport metrics and toolbar height, which is prone to
error.
MozReview-Commit-ID: 4ebI3BHEOXR
--HG--
extra : rebase_source : 264f03f3032f101687c2a39d1cf052ac1805f12b
Patch gets rid of `LayerView.getMatrixForLayerRectToViewRect`, and just
uses `LayerView.getZoomFactor` directly when calculating the matrix in
GeckoInputConnection. This also lets us avoid the `isCompositorReady`
call on a non-UI thread. To get the correct offset, we need the screen
bounds from Gecko, so it's passed to Java as the first element in the
rect array. Using bounds from Gecko lets us avoid having to deal with
things like the dynamic toolbar animator ourselves.
MozReview-Commit-ID: 6I61SZGyQyO
--HG--
extra : rebase_source : d576fb7ef9a42de10b14db662e5c4833f16f6312
Basically, widget code shouldn't access API in dom/events as far as possible
since it's difficult to care widget code when other developers to change under
dom/.
This patch backouts the patch for bug 1402461 which made GeckoEditableSupport
depend on EventStateManager in dom/events. Now, necessary information is in
InputContextAction and same condition should be shared with Windows.
MozReview-Commit-ID: LMlrizswxUj
--HG--
extra : rebase_source : c13604eac143ec5994c65571bff09887d5c0c221
Remove AndroidJavaWrappers. Convert nsJNIString usages to use
jni::String and AndroidMotionEvent usages to use java::sdk::MotionEvent.
Move key code constants to GeckoEditableSupport.cpp.
MozReview-Commit-ID: CwcGGADWCNv
Don't crash when we encounter a selection exception when in Beta. Still
crash when in Nightly so we can investigate the source of the crash.
r=me for trivial patch.
MozReview-Commit-ID: HgmudX4VfWO
