Otherwise it doesn't work with multiprocessing, which breaks debugging wpt on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D7173
--HG--
extra : moz-landing-system : lando
The templated version of Finalize is not needed, because the argument
being passed in is already an nsIURI, so the QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6862
--HG--
extra : moz-landing-system : lando
This effectively removes the devtools overhead while profiling... as
long as the toolbox isn't opened as well of course.
This also removes the performance panel from the Browser Toolbox and the
Browser Content Toolbox where it shouldn't have been in the first place.
Differential Revision: https://phabricator.services.mozilla.com/D6904
--HG--
extra : moz-landing-system : lando
This ensures that we always start from a partial manifest where possible and also ensures that the
configuration files are correctly created (a refactor to create these irrespective of whether we
do a download would make sense, but this fixes the immediate problem)
Depends on D7088
Differential Revision: https://phabricator.services.mozilla.com/D7089
Usually this directory is created by the build system. However if we
run ./mach wpt-manifest-update before trying to do a build it can
error out. Just creating the directory should be enough to fix this.
Differential Revision: https://phabricator.services.mozilla.com/D7088
These regexes are used for things like determining which tasks to run given a
"path" int |mach try|. Previously, we used patterns like:
mochitest-chrome-(?:e10s)?(?:-1)?$
This would match both e10s and non-e10s versions of a task with either no
chunks, or only selecting chunk 1. But we keep adding other configurations, e.g
-gpu, -no-accel, -sw, etc. Each time we create a new possibility we need to
remember to update these task regexes (or else lose test coverage when using
paths with |mach try|).
Instead of individually listing every possibility, let's use a pattern like
this:
mochitest-chrome($|.*(-1|[^0-9])$)
This also selects tasks that are either chunk 1 or don't have any chunks. But
it allows for arbitrary strings in-between. This regex doesn't need to be
updated when we add configurations like -sw.
Depends on D7119
Differential Revision: https://phabricator.services.mozilla.com/D7120
--HG--
extra : moz-landing-system : lando
I almost forgot to update the regexes in moztest.resolve when creating the -sw
variant of task. This adds a test to make sure we don't forget more things in
the future.
Differential Revision: https://phabricator.services.mozilla.com/D7119
--HG--
extra : moz-landing-system : lando
This patch make nsCSSFrameConstructor::CreateGeneratedContentItem() early
returns if the originating element contains an UA Widget shadow root.
Differential Revision: https://phabricator.services.mozilla.com/D6828
--HG--
extra : moz-landing-system : lando
The NEON codepaths could work, but they'd have to be converted to
MSVC-friendly assembly (or separate .asm files) first. Just disable
building them for now.
This incorporates some fixes for ccache, icecream, and a better display
output (decreasing count instead of an increasing count). It may also
let us experiment with incremental rust support, though I think that
feature still needs some more work.
MozReview-Commit-ID: 7zPGiL9Ob6N
Differential Revision: https://phabricator.services.mozilla.com/D7152
--HG--
extra : moz-landing-system : lando
Replace various custom data-types in JSScript interfaces with
mozilla::Span. This abstracts implementation details and supports
range-based for-loops. Underlying storage is unchanged, but this sets us
up to be able to more easily change it.
MozReview-Commit-ID: FDfIYsAxTA8
This patch adds a few guards to the DOM elements the videocontrols holds as
properties. Any future changes that attempt to access the blacklisted layout
properties of the DOM elements will throw.
Depends on D6725
Differential Revision: https://phabricator.services.mozilla.com/D6726
--HG--
extra : moz-landing-system : lando
Given that the videocontrols UA Widget initializes when the DOM is inserted
(as opposed to the XBL binding only when the element is visible), the code should
not be tapping into layout until it updates.
Differential Revision: https://phabricator.services.mozilla.com/D6725
--HG--
extra : moz-landing-system : lando
These are identical to the 32 bit versions and so are no longer necessary to correctly
generate moz.build files for windows.
Depends on D7101
Differential Revision: https://phabricator.services.mozilla.com/D7102
--HG--
extra : moz-landing-system : lando
