This is needed in order to implement `CreateListener()`, which is used
when DocumentChannel is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D67682
--HG--
extra : moz-landing-system : lando
This is a very performance-critical path, so we want to avoid
dispatching the value listener on a future loop iteration.
Differential Revision: https://phabricator.services.mozilla.com/D70247
--HG--
extra : moz-landing-system : lando
Converts layout.framevisibility.numscrollportwidths and layout.framevisibility.numscrollportheights to static prefs.
Differential Revision: https://phabricator.services.mozilla.com/D69615
--HG--
extra : moz-landing-system : lando
The interface changes which GeckoViewNavigation.jsm is being updated for are
performed in earlier parts. This patch just covers the required changes to
frontend code to propagate this information down to the nsFrameLoader when it is
created.
Differential Revision: https://phabricator.services.mozilla.com/D67054
--HG--
extra : moz-landing-system : lando
This is necessary to avoid the use of setOriginAttributesBeforeLoading, which is
being removed in this patch set.
Differential Revision: https://phabricator.services.mozilla.com/D67042
--HG--
extra : moz-landing-system : lando
We change a few things in this patch:
* We modify `ServiceAllocator` to support multiple bindings:
* Since Android distinguishes unique bindings via unique `ServiceConnection`
objects, we add a `Binding` class that provides that bare-bones
distinction but just forwards the `ServiceConnection` callbacks to its
`InstanceInfo` owner.
* Each `InstanceInfo` represents one content process instance, and it holds
references to between 0 and 3 `Binding` objects, one for each possible
priority level.
* After changing the current priority level of an `InstanceInfo`, we call
the `updateBindings` method to add or drop bindings as necessary to
effect the correct level.
* We add code to support the new `Context.updateServiceGroup` API starting
with Android 10. Essentially it describes to Android the relative
importance of multiple services running within the same priority level
(think of it like how we rank our P2 bugs).
* We add `GeckoProcessManager.setProcessPriority` to receive prioritization
changes from Gecko and wire that into the `ServiceAllocator`. We start new
processes with `PriorityLevel.BACKGROUND` and then Gecko subsequently adjusts
as necessary.
* Once this lands we must also set `dom.ipc.processPriorityManager.enabled=true`
to experiment with e10s-multi.
Differential Revision: https://phabricator.services.mozilla.com/D68419
--HG--
extra : moz-landing-system : lando
Per https://developer.android.com/studio/releases/build-tools, the default
version of the build tools used is internal to the Gradle plugin for Android,
which in the current version of Gradle is 28. To use 29, we need to explicitly
specify that in `.gradle` files using `buildToolsVersion`.
We also change the specification of `compileSdkVersion` to obtain that
information from the build configuration.
Differential Revision: https://phabricator.services.mozilla.com/D69632
--HG--
extra : moz-landing-system : lando
The interface changes which GeckoViewNavigation.jsm is being updated for are
performed in earlier parts. This patch just covers the required changes to
frontend code to propagate this information down to the nsFrameLoader when it is
created.
Differential Revision: https://phabricator.services.mozilla.com/D67054
--HG--
extra : moz-landing-system : lando
This is necessary to avoid the use of setOriginAttributesBeforeLoading, which is
being removed in this patch set.
Differential Revision: https://phabricator.services.mozilla.com/D67042
--HG--
extra : moz-landing-system : lando
This is a regression by bug 1509527.
I should set TYPE_TEXT_FLAG_CAP_SENTENCES for `textarea` element and
contenteditable again.
Also, Gecko doesn't set valid type hint for input element yet. So I add a
workaround to test file. It will be fixed by bug 1424284. And this fix removes
unused condition for` textarea`.
Differential Revision: https://phabricator.services.mozilla.com/D69214
--HG--
extra : moz-landing-system : lando
This test verifies that history is preserved when navigating from an extension
page to a web content page.
Today this involves going from the main process to the content process, but
when we enable remote extensions this will involve going from one content
process (the extension process) to another content process (the web process) so
to avoid forgetting about this we can introduce a test now that should still
pass in both scenarios.
Differential Revision: https://phabricator.services.mozilla.com/D69455
--HG--
extra : moz-landing-system : lando
It started, as most things do, with a software upgrade.
Upgrading the Android SDK version produced mysterious build errors:
```
java.lang.RuntimeException: ... Error while executing process /builds/worker/fetches/android-sdk-linux/build-tools/29.0.3/aidl ...
```
Looking a little further back in the log, one found the mysterious
error:
```
/builds/worker/fetches/android-sdk-linux/build-tools/29.0.3/aidl: error while loading shared libraries: /builds/worker/fetches/clang/lib/libc++.so: file too short
```
And when one investigated that file, one found that all `libc++.so` contained
was:
```
INPUT(libc++.so.1 -lc++abi)
```
which was obviously not any kind of loadable shared library.
The `libc++.so` file was meant as a redirect, an artifact placed so people
could say `-lc++` on their compiler command lines and things would Just Work.
The intent was that programs would link to `libc++.so.1` (or whatever other
soversion was in use) and that they wouldn't have to worry about `-lc++abi` or
any other private implementation details of libc++. Why, then, was `aidl`
linking to `libc++.so`?
Looking at `ldd aidl` on a local machine says:
```
...
libc++.so => $HOME/.mozbuild/android-sdk-linux/build-tools/29.0.3/./lib64/libc++.so (0x00007f8b4b2d1000)
...
```
and poking at `aidl` with `readelf --dynamic -W` indicated a partial solution
to the problem:
```
...
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib64:$ORIGIN/lib64]
...
```
`aidl` contained a `DT_RUNPATH` entry for `libc++.so` that specified to the
linker "find my `libc++.so` at a path relative to my current binary location."
Presumably this was done so that `aidl` would link to a specific `libc++.so`
and not pick up a random `libc++.so` from the system on which `aidl` was
running.
...Except that setting `LD_LIBRARY_PATH`, which we specify during our builds for
various reasons, takes precedence over `DT_RUNPATH`. So invoking `aidl` was
looking for `libc++.so` along `LD_LIBRARY_PATH`, finding this linker script
that was meant to be used only by the compiler, and attempting to use it like
a real shared library.
Great, we understand the problem now; what do we do about it?
Unwinding our use of `LD_LIBRARY_PATH` is an involved task. One further
wrinkle that wasn't mentioned above is that not every Android build that we
run failed after the SDK update: our x86-64 fuzzing build was fine, as was the
ARM PGO instrumentation build. Presumably, those builds set `LD_LIBRARY_PATH`
in slightly different ways compared to our other builds, and those differences
in setting `LD_LIBRARY_PATH` contribute to `aidl` somehow not getting invoked
with `LD_LIBRARY_PATH` set. It is not obvious to me how difficult getting a
consistent `LD_LIBRARY_PATH` setting is.
This next part is conjecture -- informed conjecture, but conjecture
nonetheless. When we invoke gradle for the first time, a separate daemon
process is started, presumably to make various Java startup problems go away.
What we would like to have happen, and what appears to happen, is that
everything that gradle does is actually spawned from the daemon itself, not
from the invoked gradle process. So if we could get the daemon invoked with
the correct environment (i.e. no `LD_LIBRARY_PATH` present), everything would
just work, because `aidl` would be launched from an environment that will
respect its `DT_RUNPATH` setting.
This change assumes that gradle does not invoke things that depend on
`LD_LIBRARY_PATH`, which is not at all clear; I think there are cases where we
can go `mach -> gradle -> mach -> ... -> clang`. But those cases don't seem
to come up in automation (perhaps due to every build being a clobber), and if
they come up on local developer machines, local developer machines seem
unlikely to have `LD_LIBRARY_PATH` set (mandatory invocation of xkcd#1172).
All of that is to say that this patch takes a semi-hacky approach to the
problem: when we invoke gradle, we make sure that we're invoking it with an
environment that doesn't contain `LD_LIBRARY_PATH`. And doing so avoids all
of the problems outlined above.
Differential Revision: https://phabricator.services.mozilla.com/D69374
--HG--
extra : moz-landing-system : lando
mozconfig.common.override is supposed to be a way for try pushes to change any options that may have been previously set. To do this effectively, it needs to be the last thing in the mozconfig.
Differential Revision: https://phabricator.services.mozilla.com/D69045
--HG--
extra : moz-landing-system : lando
Gecko uses a canary file to determine if the last startup was succesful or
not and subsequently uses that status to determine if the startup cache
should be used. The file should be deleted either on a clean
exit or after the browser has succesfully started after a delay. On
android there will never be a clean exit and file was not manually being
deleted after startup. To fix this, delete the file after all the idle
startup tasks finish.
Differential Revision: https://phabricator.services.mozilla.com/D68451
--HG--
extra : moz-landing-system : lando
`inputmode` is lower case except to `mozAwesomebar`. So it is unnecessary to
use `equalsIgnoreCase`.
Also, `mozAwesomebar` is for `inputmode`, not `type`. So this changeset has
this fix.
Differential Revision: https://phabricator.services.mozilla.com/D68332
--HG--
extra : moz-landing-system : lando
`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
--HG--
extra : moz-landing-system : lando
This flag allows embedders to know when a onLoadRequest call is generated by
the app or not. Embedders can use this to skip expensive checks in
app-generated onLoadRequest calls.
Differential Revision: https://phabricator.services.mozilla.com/D68595
--HG--
extra : moz-landing-system : lando
We change a few things in this patch:
* We modify `ServiceAllocator` to support multiple bindings:
* Since Android distinguishes unique bindings via unique `ServiceConnection`
objects, we add a `Binding` class that provides that bare-bones
distinction but just forwards the `ServiceConnection` callbacks to its
`InstanceInfo` owner.
* Each `InstanceInfo` represents one content process instance, and it holds
references to between 0 and 3 `Binding` objects, one for each possible
priority level.
* After changing the current priority level of an `InstanceInfo`, we call
the `updateBindings` method to add or drop bindings as necessary to
effect the correct level.
* We add code to support the new `Context.updateServiceGroup` API starting
with Android 10. Essentially it describes to Android the relative
importance of multiple services running within the same priority level
(think of it like how we rank our P2 bugs).
* We add `GeckoProcessManager.setProcessPriority` to receive prioritization
changes from Gecko and wire that into the `ServiceAllocator`. We start new
processes with `PriorityLevel.BACKGROUND` and then Gecko subsequently adjusts
as necessary.
* Once this lands we must also set `dom.ipc.processPriorityManager.enabled=true`
to experiment with e10s-multi.
Differential Revision: https://phabricator.services.mozilla.com/D68419
--HG--
extra : moz-landing-system : lando
We change a few things in this patch:
* We modify `ServiceAllocator` to support multiple bindings:
* Since Android distinguishes unique bindings via unique `ServiceConnection`
objects, we add a `Binding` class that provides that bare-bones
distinction but just forwards the `ServiceConnection` callbacks to its
`InstanceInfo` owner.
* Each `InstanceInfo` represents one content process instance, and it holds
references to between 0 and 3 `Binding` objects, one for each possible
priority level.
* After changing the current priority level of an `InstanceInfo`, we call
the `updateBindings` method to add or drop bindings as necessary to
effect the correct level.
* We add code to support the new `Context.updateServiceGroup` API starting
with Android 10. Essentially it describes to Android the relative
importance of multiple services running within the same priority level
(think of it like how we rank our P2 bugs).
* We add `GeckoProcessManager.setProcessPriority` to receive prioritization
changes from Gecko and wire that into the `ServiceAllocator`. We start new
processes with `PriorityLevel.BACKGROUND` and then Gecko subsequently adjusts
as necessary.
* Once this lands we must also set `dom.ipc.processPriorityManager.enabled=true`
to experiment with e10s-multi.
Differential Revision: https://phabricator.services.mozilla.com/D68419
--HG--
extra : moz-landing-system : lando
This flag allows embedders to know when a onLoadRequest call is generated by
the app or not. Embedders can use this to skip expensive checks in
app-generated onLoadRequest calls.
Differential Revision: https://phabricator.services.mozilla.com/D68595
--HG--
extra : moz-landing-system : lando
We change a few things in this patch:
* We modify `ServiceAllocator` to support multiple bindings:
* Since Android distinguishes unique bindings via unique `ServiceConnection`
objects, we add a `Binding` class that provides that bare-bones
distinction but just forwards the `ServiceConnection` callbacks to its
`InstanceInfo` owner.
* Each `InstanceInfo` represents one content process instance, and it holds
references to between 0 and 3 `Binding` objects, one for each possible
priority level.
* After changing the current priority level of an `InstanceInfo`, we call
the `updateBindings` method to add or drop bindings as necessary to
effect the correct level.
* We add code to support the new `Context.updateServiceGroup` API starting
with Android 10. Essentially it describes to Android the relative
importance of multiple services running within the same priority level
(think of it like how we rank our P2 bugs).
* We add `GeckoProcessManager.setProcessPriority` to receive prioritization
changes from Gecko and wire that into the `ServiceAllocator`. We start new
processes with `PriorityLevel.BACKGROUND` and then Gecko subsequently adjusts
as necessary.
* Once this lands we must also set `dom.ipc.processPriorityManager.enabled=true`
to experiment with e10s-multi.
Differential Revision: https://phabricator.services.mozilla.com/D68419
--HG--
extra : moz-landing-system : lando
`ServiceConnection.onServiceDisconnected` is not called if
`Context.unbindService` finished cleanly. We should be clearing `mService` in
that case.
Furthermore, if the service did die unexpectedly and
`ServiceConnection.onServiceDisconnected` was called, we need to explicitly
unbind so that Android does not automatically reconnect the binding.
Differential Revision: https://phabricator.services.mozilla.com/D68417
--HG--
extra : moz-landing-system : lando
The omni.ja file contains all the javascript code that GeckoView uses
internally. Right now the omni.ja file is compressed in the APK which causes
GeckoView to uncompress the omni.ja file in memory before it can start doing
anything else. This takes a long time, on some profiles it delays startup by
about 400ms.
Storing the omni.ja uncompressed allows GeckoView to just map it in memory
bypassing the uncompress step.
Differential Revision: https://phabricator.services.mozilla.com/D67943
--HG--
extra : moz-landing-system : lando
Converts `security.mixed_content.block_object_subrequest`, `security.mixed_content.block_display_content`, `security.mixed_content.upgrade_display_content`, and `security.mixed_content.block_active_content` to static prefs.
Differential Revision: https://phabricator.services.mozilla.com/D67205
--HG--
extra : moz-landing-system : lando
This ensures that CSS coordinates (which is what the synthesizeTap test case
passes to GeckoSessionTestRule.synthesizeTap()) are equal to Screen coordinates
(which is what that function expects).
An alternative approach would be to query the resolution and convert from CSS
to Screen coordinates, either in the test case or inside synthesizeTap().
Differential Revision: https://phabricator.services.mozilla.com/D67519
--HG--
extra : moz-landing-system : lando
When running mochitests on real hardware, we sometimes lose the network,
causing strange timeouts. It's better if we crash immediately in those
situations to avoid confusion.
Differential Revision: https://phabricator.services.mozilla.com/D67383
--HG--
extra : moz-landing-system : lando
We also don't pass `BYPASS_LOAD_URI_DELEGATE` since it's ignored anyway for
reloads.
Differential Revision: https://phabricator.services.mozilla.com/D67654
--HG--
extra : moz-landing-system : lando
When running mochitests on real hardware, we sometimes lose the network,
causing strange timeouts. It's better if we crash immediately in those
situations to avoid confusion.
Differential Revision: https://phabricator.services.mozilla.com/D67383
--HG--
extra : moz-landing-system : lando
When you type in a textarea, and zoom to position the caret, then click, we'll
scroll all the way to the top of the textarea, via:
IMEStateManager::OnClickInEditor -> SetIMEState -> SetInputContext -> mEditable->NotifyIME(EditableListener::NOTIFY_IME_OPEN_VKB);
Even if the keyboard was already displayed. In this case, we're not moving
focus, and panning to the start causes more issues than it fixes. Prevent
zooming to the start of the input in this case, but still do it if we get the
resize event (and thus toggle the keyboard).
Differential Revision: https://phabricator.services.mozilla.com/D67222
--HG--
extra : moz-landing-system : lando
That data is not the right one anyway, since it comes from the previous page
rather than the current one.
Note: this is also broken on desktop too. It will be fixed once we move to main
process history (hopefully?).
Differential Revision: https://phabricator.services.mozilla.com/D67392
--HG--
extra : moz-landing-system : lando
Converts `security.mixed_content.block_object_subrequest`, `security.mixed_content.block_display_content`, `security.mixed_content.upgrade_display_content`, and `security.mixed_content.block_active_content` to static prefs.
Differential Revision: https://phabricator.services.mozilla.com/D67205
--HG--
extra : moz-landing-system : lando
There are cases when GV is being animated and it ends up being smaller than the
dynamic toolbar for a few frames. When that happens we really don't want to
crash and we can just ignore it.
Differential Revision: https://phabricator.services.mozilla.com/D67364
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
Dylan Roeh
James Willcox
Dragana Damjanovic
Emilio Cobos Álvarez
Randall E. Barker
Kristen Wright
Nika Layzell
Aaron Klotz
sonakshi
owlishDeveloper
Mike Hommey
Agi Sferro
Cosmin Sabou
Makoto Kato
Eitan Isaacson
Nathan Froyd
Dorel Luca
Sebastian Hengst
aarushivij
David Major
Tim Nguyen
Brendan Dahl
Henri Sivonen
Dão Gottwald
MahakBansal
Bogdan Tara
Ciure Andrei
Bob Clary
Botond Ballo
Tomislav Jovanovic
Kartikaya Gupta
Petru-Mugurel Lingurar
Oana Pop Rus
Sylvestre Ledru
Stefan Hindli
William Lachance
Marco Bonardo