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
Also update documentation to suggest using the `GeneratedFile` template rather than directly referencing `GENERATED_FILES` where possible.
Differential Revision: https://phabricator.services.mozilla.com/D77496
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
There's no use case for stateful comparators, so they can be just plain
function pointers.
This is used in some hot places like CSS selector matching.
Differential Revision: https://phabricator.services.mozilla.com/D77084
I don't think all this complexity is worth it for having a
marginally-more-realistic testing story. Using the pref just works and we should
do that, I think.
Differential Revision: https://phabricator.services.mozilla.com/D59980
* We modify connection management such that we now use more specific connection
types for {content, non-content, socket process} connections.
* We attach a native counterpart to the `GeckoProcessManager.ConnectionManager`
instance that listens for app foreground, app background, and when the
socket process is enabled, network state events.
* On app background, all non-content processes are assigned BACKGROUND priority.
Even though backgrounding the app will cause Android to drop all child
processes' priority regardless of our priority settings, we still do this as
to indicate to Android that these processes are relatively less important
than our parent process.
* When the socket process is enabled, we drop its priority when we detect that
we have no network connectivity. Note that the network management code does
the Right Thing if network connectivity changes while our app was in the
background: we receive the network state change event once we return to
foreground, therefore we do not need to do any special handling ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D74478
We update the name generation code to dump the files into:
```
OBJDIR/widget/android/GeneratedJNI
```
which are then exported to `mozilla/java`
Differential Revision: https://phabricator.services.mozilla.com/D74720
It's not trivial to split the existing "unified" include declaration
into granular include declarations, so we continue generating a
unified header that can be incrementally abandoned until it can be
jettisoned.
Depends on D58572
Differential Revision: https://phabricator.services.mozilla.com/D58573
This handles the build system bits.
The subsequent patch will restore the "unified"
GeneratedJNI{Natives,Wrappers}.h header files, and will be folded into
this one before landing.
What will still remain is to update the consumers of the .h files (all
the current #include lines) to use the fine-grained imports. At that
time the "unified" header files can be removed entirely.
Differential Revision: https://phabricator.services.mozilla.com/D58572
We update the name generation code to dump the files into:
```
OBJDIR/widget/android/jni/GeneratedJNI{Natives, Wrappers}
```
which are then exported to `mozilla/jni/natives` and `mozilla/jni/wrappers`
Differential Revision: https://phabricator.services.mozilla.com/D74720
It's not trivial to split the existing "unified" include declaration
into granular include declarations, so we continue generating a
unified header that can be incrementally abandoned until it can be
jettisoned.
Depends on D58572
Differential Revision: https://phabricator.services.mozilla.com/D58573
This handles the build system bits.
The subsequent patch will restore the "unified"
GeneratedJNI{Natives,Wrappers}.h header files, and will be folded into
this one before landing.
What will still remain is to update the consumers of the .h files (all
the current #include lines) to use the fine-grained imports. At that
time the "unified" header files can be removed entirely.
Differential Revision: https://phabricator.services.mozilla.com/D58572
When content length is over 2GB, `WebResponseInfo.contentLength` is negative
value. Use Long.valueOf instead of Integer.valueOf to pass this value.
Differential Revision: https://phabricator.services.mozilla.com/D74586
This is a very first iteration of about:processes, so that people who actually need the tool can start using it immediately and provide feedback.
Differential Revision: https://phabricator.services.mozilla.com/D72617
CondVar already calls `AUTO_PROFILER_THREAD_SLEEP`, which shouldn't be called recursively.
mozilla::Monitor also uses CondVar, so it shouldn't be surrounded by `AUTO_PROFILER_THREAD_SLEEP` either.
Depends on D72850
Differential Revision: https://phabricator.services.mozilla.com/D72851
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
No one seems to reference `dom.event.touch.coalescing.enabled` after landing Bug 1291373.
So remove it.
Differential Revision: https://phabricator.services.mozilla.com/D70794
--HG--
extra : moz-landing-system : lando
Old NDK requires AKEYCODE defines for newer API version, but it is unnecessary
to define it when using NDK r20.
Differential Revision: https://phabricator.services.mozilla.com/D70786
--HG--
extra : moz-landing-system : lando
Currently, there is a cyclic reference between `ImageDecoderListener` and `ImageCallbackHelper` that causes a memory leak on Android. `ImageDecoderListener` is holding `imgIContainerCallback` which is a `ImageCallbackHelper` and `ImageCallbackHelper` is holding `imgIContainer`, which is actually a `ImageDecoderListener`.
Therefore, we should break the cyclic reference after receiving decoded image.
Differential Revision: https://phabricator.services.mozilla.com/D70468
--HG--
extra : moz-landing-system : lando
Makoto Kato
Ricky Stewart
Mihai Alexandru Michis
Emilio Cobos Álvarez
Aaron Klotz
James Willcox
Dylan Roeh
Sebastian Streich
Kartikaya Gupta
Nick Alexander
Razvan Maries
owlishDeveloper
Jean-Yves Avenard
Narcis Beleuzu
Dorel Luca
David Teller
Markus Stange
Botond Ballo
Gerald Squelart
Csoregi Natalia
Kris Taeleman
alwu