This patch makes MediaDataEncoder declare its refcounting as virtual.
This will allow a future patch in this series to add subclasses that
have multiple superclasses using refcounting.
Differential Revision: https://phabricator.services.mozilla.com/D211650
This patch makes it so we are consistent in how we teardown the GMP
video decoder, in particular when we encounter an error callback from
the plugin. We may fail during a call to initialize the decoder for
example, and should not attempt to use any GMP APIs on our proxy after
it because its internal state is default initialized and it doesn't
check always for null pointers.
Differential Revision: https://phabricator.services.mozilla.com/D211679
ShareableCanvasRenderer::UpdateCompositableClient() does not update FwdTransactionTracker::mFwdTransactionId when canvas is not dirty. It caused small emoteTextureTxnId in RecordedTextureData::~RecordedTextureData(). It caused too early remote texture owner removal. And it caused Bug 1898650 comment 2.
Differential Revision: https://phabricator.services.mozilla.com/D211713
These tasks will never fail, and don't have logs, so having them on
treeherder can be confusing.
Rename `post-signing` to `post-signing-dummy` to benefit from the
special handling in `verify_dependency_tiers`.
Differential Revision: https://phabricator.services.mozilla.com/D211746
Chrome responsiveness test have been running every Monday, Wednesday, and Friday on the general_perf_testing cron
We have been exeriencing issues with these tests, and this patches disables their running on the GPT cron
Differential Revision: https://phabricator.services.mozilla.com/D211279
As part of our okr goals of being competative in pageload we are running essential pageload tests on chrome on android to have an idea of how we compare to chrome on android
Differential Revision: https://phabricator.services.mozilla.com/D209981
This patch addresses the problem that we currently collect HTTPS-First telemetry
for sites that are not reachable at all, be it through always causing a error or
through always timing out.
- On a downgrade, do not collect telemetry instantly, but instead save the
telemetry data in the load state for the downgraded request
- That telemetry data will then be copied over into the document load listener
of the new request
- On a successful request, if we have downgrade data in the load listener, we
collect the downgrade telemetry, as the downgrade seems to have been
successful
- Similar to the downgrade case, we only count the upgrade metric once we
encounter a successful request annotated with the information that it was
upgraded by HTTPS-First, instead of counting it instantly on the decision to
upgrade. This also means the upgrade metric will not include loads that are
downgraded again anymore
- Add a testcase for a site which is neither reachable via HTTP nor HTTPS, and
ensure no telemetry is collected
Differential Revision: https://phabricator.services.mozilla.com/D210792
This switches us away from the code signing certificate expiring in
June, to a new one valid until 2027.
Update subject pin in msix repackaging and issuer pin in the stub installer.
Differential Revision: https://phabricator.services.mozilla.com/D208633
In bug 1892715 the wait states for translations changed; however,
`isTranslateProcessing` logic did not change. This is to fix `isTranslateProcessing`
to use the longer wait state.
Differential Revision: https://phabricator.services.mozilla.com/D211439
The UI test was disabled because it failed to properly verify the url after opening the learn more link.
In some cases a "too many requests" error page was displayed instead of the sumo page, most likely because of the repeated requests sent by the UI tests.
While investigating, I've noticed that after clicking the "learn more link" there's actually a redirect happening.
When the "too many requests" error occurs the redirect link is actually being displayed (https://support.mozilla.org/1/mobile/1.0.2421/Android/en-US/enhanced-tracking-protection-android)
I've searched for this link in our project and found it in the SupportUtils object.
To overcome the fact that we might need to check 2 URLs, I've created a new verifyETPURL function in which:
- We'll first try to verify the link after properly being redirected to the enhanced-tracking-protection
- If the error occurs verify the redirect link using getSumoURLForTopic from the SupportUtils object
The UI test successfully passed 200x on Firebase ✅
Differential Revision: https://phabricator.services.mozilla.com/D211538
Note that the ignore code for subprocess is being ported from the legacy worker watcher.
The Worker Target URL is now correctly set to the Absolute URL,
this has an impact on the context selector as we are displaying it.
Also, this patch highlights some issues around Common JS Loader and the distinct compartment
to be used when debugging privileged page, or when running the browser toolbox.
It caused leaks when running browser toolbox tests in debug builds.
The JS Process Actor is directly loaded in a distinct global and compartment "DevTools global",
thanks to `loadInDevToolsLoader` flag of BrowserToolboxDevToolsProcess JS Process Actor configuration.
There is no need to use `useDistinctSystemPrincipalLoader` helper as Loader.sys.mjs, loaded from
the JS Process Actor will also be loaded in the distinct global.
Then, we only need to ensure that the CommonJS Loader will also pick up the "DevTools global"
when it is loaded in that distinct global.
Things will be significantly easier once we migrate from CommonJS to ESM as the `{ global: "contextual" }`
option passed to `ChromeUtils.importESModule` will do the right thing, as well as static `import` statements.
Differential Revision: https://phabricator.services.mozilla.com/D204874
The cleanup work done from didDestroy was only calling `unwatch` on the Watcher classes,
which was typically unregistering the platform listeners.
We were missing calling `destroyTargetsForWatcher` on them which is meant to destroy
the target actors, which can also register platform listeners and be leaking data.
Differential Revision: https://phabricator.services.mozilla.com/D210366
Stop unregistering the JS Process actor when removing the last watched target/resource type.
Instead only unregister it when the Watcher Actor is destroyed.
It prevents some race condition where unwatch request (which aren't awaited for)
unregister the actor late and the next test/next toolbox opening would have its actor
unregistered by late destruction code related to the previously closed toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D210365
This is important to spawn this ESM only once between regular and browser toolbox,
and especially between various callsites used by the browser toolbox.
Otherwise we may start loading modules in two distinct system loaders
and may have inconsistancies when using `instanceof`.
Differential Revision: https://phabricator.services.mozilla.com/D207432
Modifying the content of the list of resources may suddently start or stop receiving new resources types,
that, without calling (un)watchResources again!
Differential Revision: https://phabricator.services.mozilla.com/D205603
The enhancer was brittle as nothing was waiting for its completion.
We should rather do such work from the action layer. At least this can delay the action completion,
which the test header (setFilterState) already wait for.
Differential Revision: https://phabricator.services.mozilla.com/D205602
