It's not obvious to me what the culprit is, but it may be because
of the clearOutput call somehow.
Let's see if this fix the intermittent.
Differential Revision: https://phabricator.services.mozilla.com/D52321
--HG--
extra : moz-landing-system : lando
The tests are rewritten so we only have one test per
stub type. The stubs can be re-generated by passing
the --setenv WEBCONSOLE_STUBS_UPDATE=true arg when running
mach test.
We take this as an opportunity to not store the Messages
directly, but we generate them programmatically, which would
still reveal a bug as most of the test import messages.
Since we're doing that, some messages aren't localized, so
we need to add them to the L10N fixtures we have (which is
revamped a bit as getStr was getting too complex).
Differential Revision: https://phabricator.services.mozilla.com/D51596
--HG--
extra : moz-landing-system : lando
This file provides the implementation of js/Utility.h, so it should be renamed
to match the header name.
Differential Revision: https://phabricator.services.mozilla.com/D51378
--HG--
rename : js/src/jsutil.cpp => js/src/util/Utility.cpp
extra : moz-landing-system : lando
And handle the fallout of missing #includes when compiling a non-unified build.
Differential Revision: https://phabricator.services.mozilla.com/D51376
--HG--
extra : moz-landing-system : lando
For the most part another mechanical change, except for two changes:
- In gc/Nursery.cpp and vm/DateTime.cpp, the initializer_list variants for
std::min/max are used, because the two parameter forms of min/max take const
reference parameters. And it's not possible to take the reference of a
constexpr variable which wasn't previously explicitly defined. This is just
a C++14 limitation and as soon as we compile with C++17, we can revert this
change.
- builtin/String.cpp was calling `Max(unsignedVar, 0U)` in a few places, which
led to compiler warnings, because the result is always `unsignedVar`.
Differential Revision: https://phabricator.services.mozilla.com/D51371
--HG--
extra : moz-landing-system : lando
The includes are still transitively reachable through the new "#include util/*.h" headers.
Differential Revision: https://phabricator.services.mozilla.com/D51370
--HG--
extra : moz-landing-system : lando
A single header for both memory and byte alignment functions, similar to the
standard <memory> header, which also provides memory and byte alignment related
functionality.
Differential Revision: https://phabricator.services.mozilla.com/D51367
--HG--
rename : js/src/jsutil.h => js/src/util/Memory.h
extra : moz-landing-system : lando
mozilla::Vector already provides an `eraseIf` method, so we should prefer to use
the existing method. Except that Vector::eraseIf doesn't return the number of
elements removed, but that's easy to determine manually. More annoyingly is the
use of a modifying predicate function in Zone.cpp, which prevents using
Vector::eraseIf. It looks like for that specific use case a custome `EraseIf`
function is still necessary.
Differential Revision: https://phabricator.services.mozilla.com/D51362
--HG--
extra : moz-landing-system : lando
Nursery eviction needs to be correctly interleaved with the other preparation steps since finishing the current GC can cause arbitrary code to run (and hence nursery allocations to be made) via calling the GC callbacks.
Differential Revision: https://phabricator.services.mozilla.com/D52161
--HG--
extra : source : 50b2bb645118f2650abfc9f40d409114e57746bd
extra : histedit_source : 4ee3a63419883791eceed3957fa7c328424f9e6d
This takes advantage of the browser-selection patch proposed to Puppeteer.
A --product option allows choice between 'firefox' and 'chrome'.
Puppeteer takes care of profile creation for Firefox. Additional Puppeteer
Launcher options can be passed along with --setopt.
Depends on D52313
Differential Revision: https://phabricator.services.mozilla.com/D52314
--HG--
extra : moz-landing-system : lando
Consider the following case:
<image style="list-style-image: url(foo.png)"></image>
image.style.MozAppearance = "something"
The early return was preventing us from clearing the image.
This is an ancient bug, but it has started happening in the browser chrome
because the lack of lazy frame construction for XUL elements makes us construct
elements with an outdated style, which means in this case that they wouldn't
have the -moz-appearance rule applied yet.
Differential Revision: https://phabricator.services.mozilla.com/D52112
--HG--
extra : moz-landing-system : lando
This helps with getting to the relevant parts more quickly, and a better heading scheme.
Differential Revision: https://phabricator.services.mozilla.com/D52039
--HG--
rename : toolkit/components/search/docs/SearchEngineConfiguration.rst => toolkit/components/search/docs/SearchConfigurationSchema.rst
extra : moz-landing-system : lando
