The antitracking test mini-framework is extended to run the non-blocking
callback of the tests three times, each time with a unique combination
of the network.cookie.cookieBehavior and browser.contentblocking.enabled
prefs that would cause the reject tracker cookie behavior feature to get
disabled. This works seamlessly for all test cases that do not make any
assumptions around how many times their callbacks are executed.
Note that browser_imageCache.js depends on the number of times its
non-blocking callback gets executed. As a result of this, this test
is split into three tests to test the three possible combinations of
the pref for the non-blocking callback.
We add the devtool's iframe and splitter and browser content into XUL element.
If the environment is RTL, this element order is inverted.
So this patch will add the condition of direction to decide this element order.
Differential Revision: https://phabricator.services.mozilla.com/D4035
--HG--
extra : moz-landing-system : lando
This does _not_ convert .disabled selectors on non-<form> elements such as
panel-list-items since presumably in such cases the 'disabled' class is being
used to grey-out a whole chunk of content.
For form elements, however, authors shouldn't be greying out elements with the
'disabled' class without also actually making the form element itself disabled
(e.g. with the disabled attribute).
Differential Revision: https://phabricator.services.mozilla.com/D3856
--HG--
extra : moz-landing-system : lando
Just a minor fix to use cbindgen to avoid the conversion between
basic_shape::FillRule and mozilla::StyleFillRule.
Differential Revision: https://phabricator.services.mozilla.com/D4171
--HG--
extra : moz-landing-system : lando
- Added test to `devtools/client/inspector/test/browser_inspector_sidebarstate.js`.
- Added the OS and build number to the `devtools.main::sidepanel_changed` event.
- Created an `osNameAndVersion` getter inside `telemetry.js` because this can be useful whenever an OS supports new features.
- Log the `devtools.main::tool_timer` event from `telemetry.toolOpened` and `telemetry.toolClosed` for the animation inspector, computed view, font inspector, layout view and rule view.
- Updated the `telemetry.md` document because there is little point in breaking that change out to another bug.
- Added the devtools.main::tool_timer event to Events.yaml.
Differential Revision: https://phabricator.services.mozilla.com/D3982
--HG--
extra : moz-landing-system : lando
The implementation of ToCSS for Polygon has some rule, and we could use skip_if
to handle and serialization of fill-rule. However, we should derive ToCSS for
the pair of LengthOrPercentages, so define a new type for it.
Differential Revision: https://phabricator.services.mozilla.com/D4153
--HG--
extra : moz-landing-system : lando
The AudibleAutoplayMediaOccurredObserver which I added in bug1476701 was incorrectly removed by bug1472491, it's used to notify audible autoplay event for the shield study and we should add it back.
Differential Revision: https://phabricator.services.mozilla.com/D3930
--HG--
extra : moz-landing-system : lando
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
