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
And batch them when notifying child processes.
This makes RegisterVisitedQuery potentially notify synchronously, but changes
the code to deal with it properly.
Differential Revision: https://phabricator.services.mozilla.com/D69187
--HG--
extra : moz-landing-system : lando
Add a --gpu option to 'mach android-emulator' as a convenient way to over-ride the -gpu argument
passed to the emulator.
Also check the environment for MOZ_EMULATOR_COMMAND_ARGS to allow for additional over-rides
of the emulator command line.
Differential Revision: https://phabricator.services.mozilla.com/D70914
--HG--
extra : moz-landing-system : lando
This allows other front-ends to know which permissions they should prompt for,
like GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D70102
--HG--
extra : moz-landing-system : lando
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
