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
As it turns out, javadoc output is not stable across platforms / OSs / versions
(not a big suprise).
E.g. in try this is an example line:
```
/builds/worker/checkouts/gecko/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoRuntimeSettings.java:1124: warning - Tag @link: reference not found: Autocomplete.LoginStorageDelegate.onLoginFetch onLoginFetch
```
on my mac, this is the same error:
```
/Users/asferro/workspace/mozilla-central/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoRuntimeSettings.java:1118: error: reference not found
* {@link Autocomplete.LoginStorageDelegate.onLoginFetch onLoginFetch}.
```
Notice the `-` character after `warning` in the first example and the `:`
character after the second example.
To be able to parse both this patch simiplifies the regex and also adds a
failsafe that will mark anything that contains the string "error" and "warning"
as such.
Differential Revision: https://phabricator.services.mozilla.com/D77545
`|mach lint -f treeherder|` expects lint to not fail ever, if a lint fails it's
just ignored. This means that when our javadoc errors out and fails the build
all lints are ignored.
To avoid that we add `failOnError = false` to the javadoc job so that we can
finish the build and actually report the errors.
This patch also adds gradle output `|mach lint|` to make it easier to
diagnose errors in the lint.
Differential Revision: https://phabricator.services.mozilla.com/D77373
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
`|mach lint -f treeherder|` expects lints to not fail ever, if a lint fails it's
just ignored. This means that when our javadoc errors out and fails the build
all lints are ignored.
To avoid that we add `failOnError = false` to the javadoc job so that we can
finish the build and actually report the errors.
This patch also adds gradle output `|mach lint|` to make it easier to
diagnose errors in the lint.
Differential Revision: https://phabricator.services.mozilla.com/D77373
The sender doesn't await a result, and the recipient does not send a
result. To get rid of logspam when the finalizer is invoked, simply
replace `sendRequestForResult` with `sendRequest`.
Differential Revision: https://phabricator.services.mozilla.com/D77235
This crash hits when a `RemoteException` is thrown during `onServiceConnected`.
We `unbind`, which destroys all our bookkeeping data. During this destruction,
we also attempt to retrieve the pid, which fails because we lost our binding
before we had a chance to retrieve it.
This patch adds a new exception to be thrown in this case, which we explicitly
catch in `removeContentConnection`.
Differential Revision: https://phabricator.services.mozilla.com/D77135
In Bug 1622749 a user preference for where to open new documents (from a
service worker notification) was temporarily overriden in order to quickly fix
a crash that was happening in mozilla::dom::ClientOpenWindow. The crash was
ocurring when the pref "browser.link.open_newwindow" was set to 2, meaning new
documents are opened in a new window, instead of a new tab. The reason the
browser crashed is because the path for opening a new document is different
depending on the current user setting, and in NEWWINDOW case we did not get a
browsing context returned when calling mozilla::dom::OpenWindow which resulted
in a failed assertion.
The solution is to pass in a callback to mozilla::dom::OpenWindow as part of
nsOpenWindowInfo object, and invoke that callback with a corresponding
BrowsingContext in nsFrameLoader when that browsing context is ready.
After we call mozilla::dom::OpenWindow, we wait on a promise, that will be
resolved when the callback is invoked, before executing the rest of the code
that depends on the browsing context for a newly opened document being
available.
Differential Revision: https://phabricator.services.mozilla.com/D72745
I'm keeping this patch as simple as possible so that we can uplift to beta.
I'll sort out the rest of this in follow-up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D76333
I'm keeping this patch as simple as possible so that we can uplift to beta.
I'll sort out the rest of this in follow-up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D76333
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
Rob Wu
Agi Sferro
Makoto Kato
Razvan Maries
Kris Maglione
Tomislav Jovanovic
Mihai Alexandru Michis
Bogdan Tara
Eugen Sawin
Aaron Klotz
Anny Gakhokidze
Butkovits Atila
James Willcox
Nazım Can Altınova
Emilio Cobos Álvarez
Emily Toop