I've been unable to reproduce this intermittent locally (even by creating a
"win64 ccov debug" build on Windows 10), but it has been easy enough to trigger
on try.
The failure is triggered when the test has been completed and it is unloading the test extension1,
by the `NS_ERROR_FILE_ACCESS_DENIED` error raised from Extension's `cleanupGeneratedFile`
(https://searchfox.org/mozilla-central/rev/f2ac80ab7dbde5400a3400d463e07331194dec94/toolkit/components/extensions/Extension.jsm#1835-1841).
By comparing the test behavior when it runs successfully locally and fails on try, I've been
finally able to identify what goes wrong when it fails:
The reason for the `NS_ERROR_FILE_ACCESS_DENIED` is the ScriptCache entry for the
test extension1's content script, which is created when we create and load the
test content page which triggers it, this script cache entry should be cleared
when the extension shutdown (and it is cleared when the test runs successfully)
Then, right after the content script is executed, the contentPage is closed and this
is where something goes (intermittently) wrong with the ipc (and the following pipe errors
may be related to it: https://treeherder.mozilla.org/logviewer.html#?job_id=194750915&repo=mozilla-central&lineNumber=2692-2702) and, because of that, during the extension shutdown the "Extension:Shutdown" message broadcasted
to all the process never reaches the process where the content script cache entry has been
created (as well as "Extension:FlushJarCache" message sent to ensure that the jar cache is flushed
in every process), and so the XPI file is still kept active by that process and so it fails to be
removed on windows (where the usual `NS_ERROR_FILE_ACCESS_DENIED` is raised in this kind of scenarios).
The underlying issue doesn't seem to be strictly related to the behavior that this test file is
verifying (that is "checking that the expected telemetry data is being collected when the storage
APIs are being used"), and so I think that it would be reasonable to prevent the intermittent
by fixing the test (and closing the page after we unload the test extension 1 is enough to ensure
that the script cache entry is always cleared as expected and the file can be removed successfully
when the test is exiting).
The following push to try seems to confirm it (the oranges are triggered by another unrelated test
which fails intermittently in win64 ccov builds):
- https://treeherder.mozilla.org/#/jobs?repo=try&revision=978e21c57ef084c4115703bf827306320e81bcad
Differential Revision: https://phabricator.services.mozilla.com/D4067
--HG--
extra : moz-landing-system : lando
This includes a fix for the style build script hang where pthreads fork
subprocesses, as well as a fix for ignoring the icecream file lock.
MozReview-Commit-ID: 29eNcbNtwB1
Differential Revision: https://phabricator.services.mozilla.com/D4139
--HG--
extra : moz-landing-system : lando
CreateCDMProxy in its fully qualified form is already an allowed leak, but per
bug 1477492 certain kinds of builds appear to log the unqualified function name
in leak sanitizer logs. Since the allowed list works on string matching, this
unqualified version is then not matched and tests are marked as failures. As the
source of this different behaviour is not clear, this patch makes the
unqualified function name also allowed.
Differential Revision: https://phabricator.services.mozilla.com/D4077
--HG--
extra : moz-landing-system : lando
This patch completely disables *ccov, and *jsdcov builds and tests when scheduling them through try option syntax as these build variations use a lot of resources and are rarely needed to be scheduled. The only way to schedule code coverage from now on will be with the |mach try fuzzy| tool.
Differential Revision: https://phabricator.services.mozilla.com/D3921
--HG--
extra : moz-landing-system : lando
The sidebar regressed at some point and wasn't showing
a scrollbar when it was needed. This patch fixes that
by making the sidebar overflow and adds a test to make
sure we don't regress.
Differential Revision: https://phabricator.services.mozilla.com/D3976
--HG--
extra : moz-landing-system : lando
After analyzing test_request.html it became clear that it relied on two false
assumptions:
1. It assumed that a service worker is notified that it's being installed before
any client can interact with it.
2. It assumed that a service worker will always be installed upon registration,
if it was unregistered before.
The first assumption is not backed by the spec; it seems that the opposite behavior
is the correct one (https://github.com/w3c/ServiceWorker/issues/1347). The second
assumption ignores the possibility of resurrection, where a service worker is re-
registered before getting uninstalled.
This commit addresses both problems by not relying on the installation phase,
instead passing the script URL as a search parameter and loading it at service
worker script evaluation time. It then runs the test function in response to a
message from the client.
Differential Revision: https://phabricator.services.mozilla.com/D3879
--HG--
extra : moz-landing-system : lando
When building binaries for Linux/aarch64, ./mach configure cannot generate
Makefile by the following error. So we need Linux/aarch64's gn-configs.
1:07.80 mozbuild.frontend.reader.SandboxValidationError:
1:07.80 ==============================
1:07.80 FATAL ERROR PROCESSING MOZBUILD FILE
1:07.80 ==============================
1:07.80 The error occurred while processing the following file or one of the files it includes:
1:07.80 /hg/mozilla-central/media/webrtc/trunk/webrtc/common_audio/common_audio_c_gn/moz.build
1:07.80 The error occurred when validating the result of the execution. The reported error is:
1:07.80 Source file should only be added to UNIFIED_SOURCES once: /media/webrtc/trunk/webrtc/common_audio/signal_processing/complex_bit_reverse.c
Differential Revision: https://phabricator.services.mozilla.com/D3607
--HG--
extra : moz-landing-system : lando
When you enter JS into the console, we can now syntax highlight it in
the output when CodeMirror is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D3842
--HG--
extra : moz-landing-system : lando
Since we don't block media without audio track anymore, the original telemetry scalar becomes useless.
We need to change its meaning in order to know the number of allowed autoplay without audio track.
Differential Revision: https://phabricator.services.mozilla.com/D3673
--HG--
extra : moz-landing-system : lando
Add two telemetry scarlar,
"MEDIA_BLOCKED_NO_METADATA" records how many media which was blocked because it hadn't loaded metadata yet.
"MEDIA_BLOCKED_NO_METADATA_ENDUP_NO_AUDIO_TRACK" records how many media which was blocked because it hadn't loaded metadata and ended up for being no audio track.
By collecting those data, we can know the proportion of media which should be autoplay but was blocked because of lacking metadata.
Differential Revision: https://phabricator.services.mozilla.com/D3671
--HG--
extra : moz-landing-system : lando
We would allow media without audio track to autoplay after it had loaded the metadata.
If media hasn't loaded metadata yet, we would treat it as audible media and then block it.
Differential Revision: https://phabricator.services.mozilla.com/D3670
--HG--
extra : moz-landing-system : lando
...down. The remedy to prevent the crash is to exit the loop when the
mShutdown flag is set. This does not attempt to address the underlying cause
of why the request continues to be pending, although this is also a concern.
Files changed:
netwerk/base/ProxyAutoConfig.cpp - expanded lambda containing logic of when
to stop waiting for the request to complete to include a check to the mShutdown
flag. Also logged a warning if the loop is exited because of mShutdown.
Differential Revision: https://phabricator.services.mozilla.com/D3977
--HG--
extra : moz-landing-system : lando
Bug 1470910 broke the positioning because it changed the tag name of .urlbar-input-box but didn't update the related rule in browser.css, and then bug 1480355 landed and made it worse. This patch fixes the first problem by updating the tag name in the CSS, and it fixes the second problem (and bug 1480355) by setting `direction: ltr` on .urlbar-input-box.
Differential Revision: https://phabricator.services.mozilla.com/D4015
--HG--
extra : moz-landing-system : lando
