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
