This is already the behaviour of TestUtils.waitForCondition.
Unfortunately it appears that a couple of callers were already passing async
functions as the condition to waitForCondition, which was leading to the
conditions being immediately considered fulfilled. A couple of these tests
unfortunately do not pass with a correctly behaving waitForCondition, and have
been updated to comment out the failing code.
Differential Revision: https://phabricator.services.mozilla.com/D120670
This patch doesn't cover turning the launcher process back on, because that already happens automatically during the PostUpdate process.
Differential Revision: https://phabricator.services.mozilla.com/D120507
Subscribe to memory pressure events on macOS and add crash report annotations to parent and content process crash reports that can be used to determine if the system was under memory pressure at the time of the crash.
Include the memory pressure level reported via the DISPATCH_SOURCE_TYPE_MEMORYPRESSURE dispatch with timestamps of transitions, the memory pressure level as read from the kern.memorystatus_vm_pressure_level sysctl, and a measurement of the percentage of available memory in the system read from the kern.memorystatus_level sysctl.
Differential Revision: https://phabricator.services.mozilla.com/D116725
We have the pref `browser.tabs.unloadOnLowMemory` to turn on the tab unloading
feature. Since it controlled whether we initialize the memory watcher or not
in `TabUnloader.init()`, changing it required process start.
To conduct A/B testing for this feature, our infrastructure needs to be able
to change the pref in the middle of session. So this change moves the pref
check from `TabUnloader.init()` to `TabUnloader.unloadTabAsync()`. With this,
we fully exercise the memoruy watcher regardless of the pref's value, but invokes
tab unloading only when the pref is on.
Differential Revision: https://phabricator.services.mozilla.com/D120744
I somehow assumed that |mach test| and |mach android-emalator| would share the
code that starts the emulator, but somehow, they don't. So we need to fix the
AVD path in this code path too.
We should probably eventually merge these two code paths to have one way to
launch the emulator.
Differential Revision: https://phabricator.services.mozilla.com/D120893
browser_filter-editor-04.js is frequently failing on windows/linux webrender platforms together with browser_flame-graph-01.js on windows webrender ones.
Differential Revision: https://phabricator.services.mozilla.com/D120778
It probably did something more useful in the past, but right now it's
only used to avoid throttling some overflow-causing animations.
It returns 0 everywhere except on Android (for some reason?), but in any
case it doesn't seem this would need to be a LookAndFeel integer, it
could just be a regular pref that we turn on for tests.
However the tests pass with this patch locally, so for now I'm not
adding a pref to replace it.
Differential Revision: https://phabricator.services.mozilla.com/D120871
This adds the stub API for the page data service and some basic docs. The service can be used from
xpcshell tests and the events respond with sane data. As there are no consumers currently the
in-memory cache never clears.
Differential Revision: https://phabricator.services.mozilla.com/D120498
This patch introduce an additional xpcshell test task (built on top of the other one added in D119799)
which cover explicitly the following behaviors:
- the extension service worker registrations are expected to:
- not be unregistered if the addon is shutting down as part of the application shutdown
- to be unregistered if the addon is disabled (while the application is not shutting down)
- the extension service worker is expected to:
- receive the "install" and "activate" lifecycle events when the service worker is registered for the first time
or if the addon is disabled and then re-enabled while the application is not shutting down
- not receive the "install" and "activate" lifecycle events when a previously active worker
is spawned again (in particular after the entire application is restarted)
Ideally these behavior shoud be tested by restarting the browser instance as in a real Browser instance
but asserting all these behavior from a marionette test would be a bit trickier (but I still plan to
take a look into that, at least to cover with a marionette test a subset of the expected behaviors on
browser restart).
As an additional side note, the test case introduced in this test is currently assuming that we
may not proceed with D119531, and so to avoid to hit the issue described in that patch description
this patch is currently introducing an additional test-only method to nsIServiceWorkerManager
(named reloadRegistrationsForTest) which currently does the bare minimum to mock the "Browser restart"
scenario.
If on the contrary, we decide to proceed further with D119531, the new nsIServiceWorkerManager.reloadRegistrationsForTest
helper would not be needed anymore (because we would just use the existing ServiceWorkerRegistrationInfo instance which
is basically in the same state that the new one loaded from the ServiceWorkerRegistar would be, besides the issue with the
stale WebExtensionPolicy instance stored in the principal associated to the previous service worker registration).
Differential Revision: https://phabricator.services.mozilla.com/D120351
This patch introduces a new xpcshell test that covers the behavior expected by the changes
applied from D119532.
The current testing strategy is based on the same internal Gecko platform APIs that are used
internally by Firefox DevTools internal API that about:debugging is using to detect when a worker is
spawned and terminated (based on JSProcessActors and nsIWorkerDebuggerManager) and to force spawn
a registered service worker (by calling the nsIServiceWorkerRegistrationInfo.attachDebugger method).
Differential Revision: https://phabricator.services.mozilla.com/D119799
This patch does prevent a service worker previously registered by a webextension to be spawned
if the webextension isn't enabled.
Instead of marking the service worker as disabled (e.g. as part of the registration data that we
store on disk), this patch is currently adding an additional check in
ServiceWorkerPrivateImpl::SpawnIfNeeded to make it early exit with an error if:
- the worker principal has a moz-extension url
- and it does not have a WebExtensionPolicy or the WebExtensionPolicy is not active
(which would mean that the extension was being uninstalled or disabled)
Differential Revision: https://phabricator.services.mozilla.com/D119532
This patch introduces changes to parent/ext-backgroundPage.js and Extension's shutdown methods to make sure
that all service workers registered by an extension are unregistered when the extension is shutting down,
unless the application is also shutting down (in which case the registration is not unregistered because
for the already installed extenson the previously activeWorker is expected to be still active across browser
restarts).
These changes prevent also to hit the issue that D119532 was triggering when an extension was reloaded
and it does not need any of the changes to ContentPrincipal::AddonPolicy from D119531.
Differential Revision: https://phabricator.services.mozilla.com/D119903
This code path is now the same as getGMPVideoDecoder, so we can merge them into
one and remove the decrypting decoder specific case.
Differential Revision: https://phabricator.services.mozilla.com/D120649
This adds the stub API for the page data service and some basic docs. The service can be used from
xpcshell tests and the events respond with sane data. As there are no consumers currently the
in-memory cache never clears.
Differential Revision: https://phabricator.services.mozilla.com/D120498