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
We won't need these suspend states anymore which were used for media control and audio focus on Fennec.
Differential Revision: https://phabricator.services.mozilla.com/D65265
--HG--
extra : moz-landing-system : lando
Mistakenly removed these lines which are still needed until we remove the
deprecated API.
Differential Revision: https://phabricator.services.mozilla.com/D65594
--HG--
extra : moz-landing-system : lando
An extension with an onUpdateAvailable listener should delay automatic
updating of the extension until the app is restarted. Add support for this
state and reject the update result with a new install error code.
Differential Revision: https://phabricator.services.mozilla.com/D65228
--HG--
extra : moz-landing-system : lando
Before this patch, the TabDelegate was "special" as in it had just one global
delegate that receives events for all extensions and sessions. This was done to
allow mochitests to call tabs.create and tabs.remove.
This hack is no longer needed as now we can notify the embedding layer that a
new extension has been installed and we have a way to list currently installed
extensions.
This patch makes TabDelegate behave the same as the other delegates
(ActionDelegate and MessageDelegate) and will allow further simplications of
the WebExtension Delegate code.
Differential Revision: https://phabricator.services.mozilla.com/D64799
--HG--
extra : moz-landing-system : lando
Android does not currently have anything similar to a 'required' state
to indicate that a field or input is required before submission. In this
patch we append a localized "required" string onto the node's hint.
The hint typically has the description of the node. If the node is an
entry the hint will have its label followed by the description.
Differential Revision: https://phabricator.services.mozilla.com/D65215
--HG--
extra : moz-landing-system : lando
Before this patch, the TabDelegate was "special" as in it had just one global
delegate that receives events for all extensions and sessions. This was done to
allow mochitests to call tabs.create and tabs.remove.
This hack is no longer needed as now we can notify the embedding layer that a
new extension has been installed and we have a way to list currently installed
extensions.
This patch makes TabDelegate behave the same as the other delegates
(ActionDelegate and MessageDelegate) and will allow further simplications of
the WebExtension Delegate code.
Differential Revision: https://phabricator.services.mozilla.com/D64799
--HG--
extra : moz-landing-system : lando
|get domFileOrDirectory| is sync so we cannot return a promise from there. We
instead resolve the DOMFile before returning from the file picker callback
which is async already.
Differential Revision: https://phabricator.services.mozilla.com/D65193
--HG--
extra : moz-landing-system : lando
Add a version of GeckoSession.reload that takes LOAD_FLAGS_* so
that it is possible to bypass caches and proxies on reload.
Differential Revision: https://phabricator.services.mozilla.com/D64809
--HG--
extra : moz-landing-system : lando
This class is not technically the thread itself, it's the runnable that the
sampling thread uses. This name is more accurate and clear for it.
Differential Revision: https://phabricator.services.mozilla.com/D64753
--HG--
extra : moz-landing-system : lando
Currently we only profile the Java Main Thread, and don't profile anything
else. This is not ideal, but this is how it works right now. And inside the
code index `0` was hardcoded on the most parts of the code. We can rollback
this patch once we want to implement profiling more than one thread, or we can
think about something more clever.
Differential Revision: https://phabricator.services.mozilla.com/D64752
--HG--
extra : moz-landing-system : lando
Design mode is different for event target, so I turn off it now. But this is enough for input and contenteditable.
Differential Revision: https://phabricator.services.mozilla.com/D64893
--HG--
extra : moz-landing-system : lando
This also makes `GeckoView#onTouchEvent()` always return `true`, because
returning `false` will cause us to not receive any more events for that
touch. We always want to receive events.
Differential Revision: https://phabricator.services.mozilla.com/D64781
--HG--
extra : moz-landing-system : lando
The Android-Gradle build plugin has evolved, as has GeckoView (it now
expects libraries in `libs/` instead of `assets/`), so we need to
ensure the libraries are copied into place at the right time.
To test this, you can use an artifact build. Run `./mach build`, and
then binary edit a string in `$TOPOBJDIR/dist/bin/libxul.so` (I used
Emacs and `bbe` to do that). Run `./mach android
build-geckoview_example`, and then verify the updated string has been
packaged, for example with something like:
```
unzip -c $TOPOBJDIR/gradle/build/mobile/android/geckoview_example/outputs/apk/withGeckoBinaries/debug/geckoview_example-withGeckoBinaries-debug.apk lib/x86_64/libxul.so | strings | grep NEW 'STRING'
```
Coincidentally, this is essentially the same issue as
https://github.com/mozilla/application-services/issues/2659.
Differential Revision: https://phabricator.services.mozilla.com/D64430
--HG--
extra : moz-landing-system : lando
In GeckoView every window has always exactly only one browser. Also selectedTab
is not defined.
Differential Revision: https://phabricator.services.mozilla.com/D64425
--HG--
extra : moz-landing-system : lando
Make it a regular stylesheet.
This allows it to be cached in shared memory if possible, and will allow me to
stop adding the stylesheet based on a pref for bug 1618202.
Differential Revision: https://phabricator.services.mozilla.com/D64377
--HG--
rename : mobile/android/themes/geckoview/content.css => layout/style/res/geckoview.css
extra : moz-landing-system : lando
Make it a regular stylesheet.
This allows it to be cached in shared memory if possible, and will allow me to
stop adding the stylesheet based on a pref for bug 1618202.
Differential Revision: https://phabricator.services.mozilla.com/D64377
--HG--
rename : mobile/android/themes/geckoview/content.css => layout/style/res/geckoview.css
extra : moz-landing-system : lando