Bug 1419488 moved AudioSession shutdown to a background thread on Windows 7 because it was leading to shutdown timeouts there. Since then, audio seems to be inspiring timeouts on other versions of Windows as well. This patch extends the Windows 7 work to all versions of Windows.
Bug 1430907 is removing AudioSession from content processes. This is the only place we have seen these crashes but AudioSession is also used in the main and plugin processes, so we want this patch to preempt issues with those processes.
Differential Revision: https://phabricator.services.mozilla.com/D64465
--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
This will eagerly generate all of the manifests and hold them all at once in memory, but only for Python 2. If that causes problems, we should complete the port to Python 3.
Differential Revision: https://phabricator.services.mozilla.com/D66090
--HG--
extra : moz-landing-system : lando
The telemetry for this window of time on Nightly is clean, so this
should be safe to bump up.
Differential Revision: https://phabricator.services.mozilla.com/D66173
--HG--
extra : moz-landing-system : lando
Before Bug 1530908, the build script used `TryToolsMixin.try_message_has_flag`
to dectect a request for artifact builds. Since that is no longer used, we can
remove the dependency.
Differential Revision: https://phabricator.services.mozilla.com/D65842
--HG--
extra : moz-landing-system : lando
The wpt harness spends a lot of time — about 20% of the total runtime
on Linux64 — between tests. The majority of this is shutting down and
restarting the Firefox instance under test. To reduce this
overhead we add the option to preload a Firefox instance which can be
immediately used when a new session is required. This makes the slow
process of creating a profile and starting the browser
asynchronous. Testing shows that this cuts the between-test time to
between a half and a third of the previous value.
The cost of this change is that we are adding background load at the
time tests are running, which could influence the results and add
randomness. However that seems unlikely unless we are right on the
edge of the system performance.
Differential Revision: https://phabricator.services.mozilla.com/D64954
--HG--
extra : moz-landing-system : lando
Use mozlog to handle logging from the `mach puppeteer-test`
command. This makes the output compatible with treeherder and allows
generating error summaries that can be used by the push-health
feature.
Presently the integration is based on parsing the output from mocha
with regex since that's easy to implement without digging into the
many layers of js code too much. In time it might make sense to
replace this with a custom output formatter integrated into mocha
itself.
We also add the ability to store and use expected results, so that we
are able to detect regressions even when not all test are passing. The
format of expected results is Dict[String, List[String]], where the
keys are test names and the values are lists of statuses. If the list
has more than one value the remaining values are treated as possible
intermittent statuses.
The updated expected statues can be generated by passing the
--write-results flag to the mach command.
Differential Revision: https://phabricator.services.mozilla.com/D65700
--HG--
extra : moz-landing-system : lando