Screenshots moved from a Photon page action to a pure WebExtension page
action, but this move introduced some UI bugs where the two page actions
behave differently. Since this change isn't needed for 63, seems better
to just temporarily revert.
Differential Revision: https://phabricator.services.mozilla.com/D4162
--HG--
extra : moz-landing-system : lando
The transition property in this test is shorter than the period of chaging
parent viewport height so that it's possible that a new transition happens
after a transitionend event was dispatched. The new transition will reduce
the element width (i.e. it's opposite direction of the first transition),
so the transitioned yellow box was smaller than the expected result.
Differential Revision: https://phabricator.services.mozilla.com/D4183
There is another transition for height property, it's possible that the received
event is for the height property transition.
Differential Revision: https://phabricator.services.mozilla.com/D4181
When different translation units contain the same symbol name, all
static, but one of them non-static, ld64 wrongfully link the references
to the static data with the non-static data, or vice versa. With libaom
and libvpx sharing data structures with the same name but different
contents, that leads to interesting failures/crashes at runtime.
This was apparently fixed in Apple ld64 from Xcode 9, but the last open
sourced version is the one from Xcode 8, so I ended up digging in the
ld64 source code and fixed the issue.
This work was merged to cctools-port upstream in
https://github.com/tpoechtrager/cctools-port/pull/59.
For the same reason as invoked in bug 1478917, though, updating to
cctools-port master is more involved than just changing a commit sha1
(as it requires building apple-libtapi, which in turn builds parts of
LLVM, which should probably be avoided), so just cherry-pick the fix.
When different translation units contain the same symbol name, all
static, but one of them non-static, ld64 wrongfully link the references
to the static data with the non-static data, or vice versa. With libaom
and libvpx sharing data structures with the same name but different
contents, that leads to interesting failures/crashes at runtime.
This was apparently fixed in Apple ld64 from Xcode 9, but the last open
sourced version is the one from Xcode 8, so I ended up digging in the
ld64 source code and fixed the issue.
This work was merged to cctools-port upstream in
https://github.com/tpoechtrager/cctools-port/pull/59.
For the same reason as invoked in bug 1478917, though, updating to
cctools-port master is more involved than just changing a commit sha1
(as it requires building apple-libtapi, which in turn builds parts of
LLVM, which should probably be avoided), so just cherry-pick the fix.
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
