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
This establishes a "high-water" mark that will make new files not be
"unified", and will allow to burn down the list of files require
unification.
Depends on D58573
Differential Revision: https://phabricator.services.mozilla.com/D58574
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
1. `GeckoProcessManager.ConnectionManager.onStartComplete` is called later than
it ideally should be; it would be better to do this as soon as binding is
complete, rather than as soon as `start` is complete. To accomplish this:
* We rename `onStartComplete` to `onBindComplete` and call it as soon as we
have successfully bound.
* We call `IChildProcess.getPid` as soon as we're bound and immediately clean
up if that fails.
* This implies that `getPid` should always have a pid and should not need to
call into `IChildProcess` during the remaining lifetime of the connection.
This allows us to eliminate exception throwing from `getPid`, and thus we may
also remove `getPidFallible`.
* This also means that we no longer need to explicitly call `getPid` in
`GeckoProcessManager.preload`.
2. We also use `XPCOMEventTarget.runOnLauncherThread` so that we do not need to
bounce through the launcher thread's event queue unnecessarily.
3. I noticed that we do not unbind the connection if the start fails but we
are not retrying. We should be unbinding regardless of whether we are going
to retry.
Differential Revision: https://phabricator.services.mozilla.com/D74500
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
WebExtensionPolicy.getByID(id) will return a stub when called earlier during
startup. Once the startup process is complete, this object is sawpped with the
real extension policy.
Before this patch, we used to hold onto the stub object, which makes it so that
we read incorrect values even though we are waiting for the policy to be ready.
To fix this we just read the result value of the readyPromise promise.
Differential Revision: https://phabricator.services.mozilla.com/D74459
Installed privileged addons in GeckoView sometimes need to send messages from
content scripts. Today we use the in-memory flag `ALLOW_CONTENT_MESSAGING` to
allow a specific built-in addon to send messages from content scripts, but for
installed extensions we need a way to persist this flag.
To do this, this patch introduces a new privileged permission
`nativeMessagingFromContent`, when this permission is present in the manifest,
the addon will be allowed to send native messages from content scripts (note:
the addon will also need `nativeMessaging` as usual).
When the permission is not present, any attempt to send a native message from a
content script will result in an error, similarly to what happens before this
patch.
Differential Revision: https://phabricator.services.mozilla.com/D72976
Sometimes extensions call tabs.create immediately on startup. In that case the
delegate may not be attached yet. To avoid losing these messages we store them
until a delegate is attached.
This also includes a refactoring to unify behavior for delegates. Eventually I
want to factor out delegates similarly to what happens in GeckoSession today.
Differential Revision: https://phabricator.services.mozilla.com/D72975
We use this to send a default action to the embedder, but if no one is
listening there's no point, and it causes problems in tests because sometimes
the delegate is attached / reattached too quickly and the second delegate will
end up getting two messages by mistake.
Differential Revision: https://phabricator.services.mozilla.com/D72974
Installed privileged addons in GeckoView sometimes need to send messages from
content scripts. Today we use the in-memory flag `ALLOW_CONTENT_MESSAGING` to
allow a specific built-in addon to send messages from content scripts, but for
installed extensions we need a way to persist this flag.
To do this, this patch introduces a new privileged permission
`nativeMessagingFromContent`, when this permission is present in the manifest,
the addon will be allowed to send native messages from content scripts (note:
the addon will also need `nativeMessaging` as usual).
When the permission is not present, any attempt to send a native message from a
content script will result in an error, similarly to what happens before this
patch.
Differential Revision: https://phabricator.services.mozilla.com/D72976
Sometimes extensions call tabs.create immediately on startup. In that case the
delegate may not be attached yet. To avoid losing these messages we store them
until a delegate is attached.
This also includes a refactoring to unify behavior for delegates. Eventually I
want to factor out delegates similarly to what happens in GeckoSession today.
Differential Revision: https://phabricator.services.mozilla.com/D72975
We use this to send a default action to the embedder, but if no one is
listening there's no point, and it causes problems in tests because sometimes
the delegate is attached / reattached too quickly and the second delegate will
end up getting two messages by mistake.
Differential Revision: https://phabricator.services.mozilla.com/D72974
To support this API, we do the following:
Additions to `GeckoSessionTestRule`:
* We add an overload to `webExtensionApiCall` that accepts a `GeckoSession`
argument. Instead of sending the message to the extension's background script,
this overload instead sends the message to the port for the session's
content script.
* We add `GeckoSessionTestRule.getSessionPid()` which uses the new
`webExtensionApiCall` overload. Moving other existing APIs over to use the
new overload is out of scope for this bug and should be done in follow-ups.
Additions to the `test-support` extension:
* We modify the content script to receive an API call message from the native
port. It then forwards the request up to the background script. By doing it
this way, the background script will receive the message along with the
WebExtension `Tab` object belonging to the sender;
* The background script's message handler merges the tab into the arguments
to the API as a `tab` property;
* The background script then calls the API and the result is returned to
the harness using the native port, just like the normal implementation;
* We add a `GetPidForTab` API for resolving top-level PIDs from a webext tab id.
Differential Revision: https://phabricator.services.mozilla.com/D73723
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
When exporting the addon object, the extension policy sometimes is not ready
yet (very common when `list()` is called at startup), so we need to wait until
it's ready or the values in it will not be correct.
Differential Revision: https://phabricator.services.mozilla.com/D73770
These support the new implementation of the addon blocklist (bug 1620621),
which is a more space-efficient way to represent the blocklist.
A comparison of file size was given in D73159. In short, 913KB for the
old JSON-based blocklist (addons.json), 64KB for the new one.
In practice, addons.json is 273KB compressed.
The new blocklist (addons-mlbf.bin) does not compress that well since it
is already an efficiently packed binary format.
Differential Revision: https://phabricator.services.mozilla.com/D73438
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
We need to move these tests to their own class so that we can add a `@Before`
function to set up the expected start conditions.
We also need to allocate the second session in such a way that it is
hosted by the same content process as `mainSession`.
The previous scheme of waiting on each `GeckoResult` independently caused
deadlocks if the results are resolved in a different order, so I replaced those
two waits with a `GeckoView.allOf` result that will Just Work (TM).
Note that this scheme works both in single-e10s and multi-e10s
configurations.
Differential Revision: https://phabricator.services.mozilla.com/D67067
Turn on some tests for InputConnection's behaviors. `inputConnection_setSelection` and `inputConnection_bug1133802` are still disabled due to Gecko issue and no good events.
Although I repeat 30 times to run this after this, no error now.
Differential Revision: https://phabricator.services.mozilla.com/D71151
Actually, we use `Thread.sleep` to get next sampling duration. But as long as
old comment, this sampling min duration is 10ms. But when I test
`Executors.newSingleThreadScheduledExecutor` on old device (10 year's old
Galaxy Nexus) instead of Thread.sleep, it can use 2ms sampling duration.
So we should use ScheduledExecutorService instead.
Differential Revision: https://phabricator.services.mozilla.com/D70401
`DeleteSelection*()` are members of `TextEditor`, but they are also used by
`HTMLEditor`. Therefore, they and pref cache members for them should be
in `EditorBase` too.
Depends on D71911
Differential Revision: https://phabricator.services.mozilla.com/D72290
We don't currently restart the extension process and this causes extensions to
randomly stop working when Android kills the extension process.
We can re-enable it once Bug 1355239 is fixed.
Differential Revision: https://phabricator.services.mozilla.com/D71790
This patch removes the allowLinkedWebInFileUriProcess pref, but one
code-path is kept because when DocumentChannel is disabled a HTTP POST load
from a file:// page would loose the postData, so that case keeps the FILE
remote type.
Differential Revision: https://phabricator.services.mozilla.com/D69923
It makes no sense that the first thing in the session would be considered as
wrapping, it was happening only because we were incorrectly failing to find a
"visible" range deep in Gecko (so we started back from the beginning of the
document, wrapping).
Differential Revision: https://phabricator.services.mozilla.com/D71157
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
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
This allows us to asynchronously wait for a given `GeckoThread` state
to be reached.
Differential Revision: https://phabricator.services.mozilla.com/D66585
--HG--
extra : moz-landing-system : lando
The extension background page should be loaded when either an event needs
to be sent to it or after the browser has started up. When an extension
is updated the special startup event listeners do not appear to be built
yet and GeckoView was not sending browser started notification, which meant the
background page never being loaded.
Differential Revision: https://phabricator.services.mozilla.com/D66717
--HG--
extra : moz-landing-system : lando
Make the GeckoResult<WebExtension> returned by WebExtensionControll.install(BuiltIn) cancellable
Differential Revision: https://phabricator.services.mozilla.com/D64953
--HG--
extra : moz-landing-system : lando
This is both for future proofing (fetches could move any time although
they likely won't), and to fix the path on the future Windows PGO
cross builds, where the fetches path is not under $WORKSPACE.
Differential Revision: https://phabricator.services.mozilla.com/D66358
--HG--
extra : moz-landing-system : lando
We'll want to make some changes to this test when we enable e10s-multi by
default, but for now we just need to update the name of the single content
process to reflect the naming changes that were done in part 1 of this
patch series.
Differential Revision: https://phabricator.services.mozilla.com/D65641
--HG--
extra : moz-landing-system : lando
We change a lot of things in this patch:
* `ChildConnection` now inherits from `ServiceAllocator.InstanceInfo`, which
imbues the former with service allocation superpowers.
* We remove the `IBinder.linkToDeath` call and the `IBinder.DeathRecipient`
callback; a close review of the service binding APIs (and the actual
Android source code) clearly shows that
`ServiceConnection.onServiceDisconnected` already performs that role.
* We also greatly simplify unbinding, as a successful `Context.unbindService`
call does not require a subsequent `onServiceDisconnected` notification;
The `ServiceConnection` callbacks should be thought of as pertaining to
the acquisition and loss of `Binder` connections. On that note, to improve
the clarity of what those callbacks do, we now implement them as
`onBinderConnected` and `onBinderConnectionLost` overrides originating from
`ServiceAllocator.InstanceInfo`.
* We add the `ConnectionManager` class which handles the organization of
tracking which processes exist with which pid. Its public methods are named
such that it should be very clear what their purposes are.
* This patch adds a minimal amount of priority management code to
`ConnectionManager`. Right now we assume that everything is running at
`PriorityLevel.FOREGROUND` (i.e. `Context.BIND_IMPORTANT`). This will be
further improved in bug 1620145.
Differential Revision: https://phabricator.services.mozilla.com/D65640
--HG--
extra : moz-landing-system : lando
For testing purposes, we'll only support 3 at the moment.
Note that this does not materially affect our test builds, as e10s-multi is
still govered by the `dom.ipc.processCount` Gecko pref.
Differential Revision: https://phabricator.services.mozilla.com/D65639
--HG--
extra : moz-landing-system : lando
`ServiceAllocator` wraps the various `Context.bindService` APIs and manages
the allocation of service names (in the case of non-isolated services) or
instance names (in the case of isolated services on Android 10+).
During the first allocation of a content process, we construct a policy that
is used for all content process allocations.
The `DefaultContentPolicy` computes the maximum number of content processes
and then allocates those names using a `BitSet`.
The `IsolatedContentPolicy` tracks the number of live content processes, but
simply uses a monotonically-increasing counter for generating instance IDs.
This patch also adds a `ServiceUtils` class that contains numerous functions
relating to generating service names and retrieving information about
service definitions in this package.
* Content processes are now named `tab0` through `tabN`. When a single content
process name is used (either for single-e10s or for the process name
used by isolated services), we always use `tab0`.
* I am not wedded to the names of the priorities used in the `PriorityLevel`
enum -- suggestions welcome!
* Some of the `ServiceUtils` functions could arguably go into `ContextUtils`
instead, but I thought that this was fine since they are fairly specific
to this use case.
* Further modifications will need to be made to support multiple priorities.
This patch is enough to get everything up and running for testing, with
further prioritization work being done in bug 1620145.
Differential Revision: https://phabricator.services.mozilla.com/D65636
--HG--
extra : moz-landing-system : lando
We'll want to make some changes to this test when we enable e10s-multi by
default, but for now we just need to update the name of the single content
process to reflect the naming changes that were done in part 1 of this
patch series.
Differential Revision: https://phabricator.services.mozilla.com/D65641
--HG--
extra : moz-landing-system : lando
We change a lot of things in this patch:
* `ChildConnection` now inherits from `ServiceAllocator.InstanceInfo`, which
imbues the former with service allocation superpowers.
* We remove the `IBinder.linkToDeath` call and the `IBinder.DeathRecipient`
callback; a close review of the service binding APIs (and the actual
Android source code) clearly shows that
`ServiceConnection.onServiceDisconnected` already performs that role.
* We also greatly simplify unbinding, as a successful `Context.unbindService`
call does not require a subsequent `onServiceDisconnected` notification;
The `ServiceConnection` callbacks should be thought of as pertaining to
the acquisition and loss of `Binder` connections. On that note, to improve
the clarity of what those callbacks do, we now implement them as
`onBinderConnected` and `onBinderConnectionLost` overrides originating from
`ServiceAllocator.InstanceInfo`.
* We add the `ConnectionManager` class which handles the organization of
tracking which processes exist with which pid. Its public methods are named
such that it should be very clear what their purposes are.
* This patch adds a minimal amount of priority management code to
`ConnectionManager`. Right now we assume that everything is running at
`PriorityLevel.FOREGROUND` (i.e. `Context.BIND_IMPORTANT`). This will be
further improved in bug 1620145.
Differential Revision: https://phabricator.services.mozilla.com/D65640
--HG--
extra : moz-landing-system : lando
For testing purposes, we'll only support 3 at the moment.
Note that this does not materially affect our test builds, as e10s-multi is
still govered by the `dom.ipc.processCount` Gecko pref.
Differential Revision: https://phabricator.services.mozilla.com/D65639
--HG--
extra : moz-landing-system : lando
`ServiceAllocator` wraps the various `Context.bindService` APIs and manages
the allocation of service names (in the case of non-isolated services) or
instance names (in the case of isolated services on Android 10+).
During the first allocation of a content process, we construct a policy that
is used for all content process allocations.
The `DefaultContentPolicy` computes the maximum number of content processes
and then allocates those names using a `BitSet`.
The `IsolatedContentPolicy` tracks the number of live content processes, but
simply uses a monotonically-increasing counter for generating instance IDs.
This patch also adds a `ServiceUtils` class that contains numerous functions
relating to generating service names and retrieving information about
service definitions in this package.
* Content processes are now named `tab0` through `tabN`. When a single content
process name is used (either for single-e10s or for the process name
used by isolated services), we always use `tab0`.
* I am not wedded to the names of the priorities used in the `PriorityLevel`
enum -- suggestions welcome!
* Some of the `ServiceUtils` functions could arguably go into `ContextUtils`
instead, but I thought that this was fine since they are fairly specific
to this use case.
* Further modifications will need to be made to support multiple priorities.
This patch is enough to get everything up and running for testing, with
further prioritization work being done in bug 1620145.
Differential Revision: https://phabricator.services.mozilla.com/D65636
--HG--
extra : moz-landing-system : lando
Add GeckoSession.PermissionDelegate.PERMISSION_MEDIA_KEY_SYSTEM_ACCESS
for when media.eme.require-app-approval=true
Differential Revision: https://phabricator.services.mozilla.com/D65423
--HG--
extra : moz-landing-system : lando
Currently the preferences for remote profiling are stored on the debuggee. This leads
to a negative user experience, as oftentimes phones do not persist the preferences.
This patch changes the strategy to store one set of preferences for local profiling,
and a second set of preferences for remote profiling.
Differential Revision: https://phabricator.services.mozilla.com/D65148
--HG--
extra : moz-landing-system : lando
This removes the obsolete backend. Notes on some of the less obvious changes
made as part of this patch:
- some of the gFoo style getters in Blocklist.jsm were only used by the XML
version of the blocklist; I've removed them and tried to remove spurious
settings of those properties in the remaining tests.
- some utility methods (e.g. distribution information getters) were also only
used for the XML version (for the update URL).
- it's no longer necessary to test switching implementations.
- in browser/base/content/test/plugins/, we ran some tests from two manifests
in order to run them with both blocklist backends. The simplest way of
reducing this back down to one was to remove the remote-settings one. If I'd
been more future-oriented when I created the duplication, perhaps I would
have moved the XML version out into a different manifest instead, but I
didn't, so now it looks like we're removing the modern one, whereas really
we're going to be running the modern one as part of the "normal" tests and
we're no longer running the "old" tests.
- removed all mentions I could see of extensions.blocklist.url which is no
longer used for anything.
- per https://bugzilla.mozilla.org/show_bug.cgi?id=1016555#c23, updated
references for the OneCRL timing and how it relates to blocklist updates.
Differential Revision: https://phabricator.services.mozilla.com/D64933
--HG--
extra : moz-landing-system : lando
Agi Sferro
Razvan Maries
Nick Alexander
Aaron Klotz
Mike Conley
Makoto Kato
Bogdan Tara
owlishDeveloper
Nikita Kozhemiakin
Dylan Roeh
Atique Ahmed Ziad
John Lin
Simon Giesecke
Csoregi Natalia
Mihai Alexandru Michis
Ian Moody
Rob Wu
jayati
Shane Caraveo
Masayuki Nakano
Ricky Stewart
Paul Bone
Kartikaya Gupta
alwu
Emilio Cobos Álvarez
Coroiu Cristina
Gijs Kruitbosch
pbz
Eitan Isaacson
Geoff Brown
Dana Keeler
James Willcox
Dragana Damjanovic
Randall E. Barker
Kristen Wright
Nika Layzell
sonakshi
Mike Hommey
Cosmin Sabou
Nathan Froyd
Dorel Luca
Sebastian Hengst
aarushivij
David Major
Tim Nguyen
Brendan Dahl
Henri Sivonen
Dão Gottwald
MahakBansal
Ciure Andrei
Bob Clary
Botond Ballo
Tomislav Jovanovic
Petru-Mugurel Lingurar
Oana Pop Rus
Sylvestre Ledru
Stefan Hindli
William Lachance
Marco Bonardo
Brendan Dahl
Thomas Wisniewski
Mike Shal
Eugen Sawin
Kashav Madan
Daniel Varga
Greg Tatum
Mark Banner
championshuttler