For some reason Telemetry's gtests doesn't like one or more of the dependencies
of mprio.h, so I had to move it into PrioEncoder's cpp and forward declare the
PublicKey typedefs.
It isn't the cleanest, but I'm surprised C++ let me off with just that level
of nonsensery.
Differential Revision: https://phabricator.services.mozilla.com/D22605
--HG--
extra : moz-landing-system : lando
The default color dictionary is implemented, to avoid formattor specifying the colors discretely
Differential Revision: https://phabricator.services.mozilla.com/D24196
--HG--
extra : moz-landing-system : lando
Depends on D21673
The test is already relying on events triggered by the destroy method of the front to progress
I don't think having a flag brings anything here.
Differential Revision: https://phabricator.services.mozilla.com/D21675
--HG--
extra : moz-landing-system : lando
This patch will remove the very long wait on start and stop,
should be down to one second.
Differential Revision: https://phabricator.services.mozilla.com/D23668
--HG--
extra : moz-landing-system : lando
Bug 1534522 added win64-aarch64-eme/opt builds, which are artifact builds
that glue together a win64-aarch64/opt build and a win32/opt build.
This enables EME on the corresponding nightlies in a slightly different
way:
- this adds a no-eme build that corresponds to win64-aarch64/opt.
- this turns the existing nightly into an artifact build that glues
together that no-eme build and the win32 nightly.
The no-eme build cannot have the nightly attribute set, first because
the beetmover transform fails in that case, and because that would imply
shipping those builds, but they're not meant to be shipped this way.
It also has run-on-projects set to an empty list so that it doesn't
appear by default in `mach try fuzzy`, while still being triggered when
needed due to being a dependency of the nightly build.
It is preferable to keep the win64-aarch64{,-eme}/opt builds untouched
to make things easier for try (the win64-aarch64 ones being the main
ones to try; also, the -eme builds currently fail with --artifacts).
Ideally, like in bug 1534522, we'd add a diffoscope build to ensure
the variations between the nightly and its base no-eme build are within
control, but currently, that would trigger nightlies on every push,
which is not desirable. Ideally, they'd trigger whenever both their
dependencies are in the target task graph. We leave that to a followup.
Differential Revision: https://phabricator.services.mozilla.com/D23640
We need to have full symbols uploaded for the upcoming EME-enabled
win64-aarch64 nightlies, and the tasks to do that are derived from the
nightly itself, which is going to be an artifact build. Bug 1527463 took
care of adding the option to enable that, and we turn it on for
EME-enabled builds.
MOZ_ARTIFACT_TASK_WIN32_OPT is not exactly the right thing, but we're
already using it to enable EME in
browser/config/mozconfigs/win64-aarch64/common-opt and is only set on
those builds.
Differential Revision: https://phabricator.services.mozilla.com/D23639
Replace a couple of popup methods so that they call dirtyFrame(), so that reflows happen deterministically.
Differential Revision: https://phabricator.services.mozilla.com/D23734
--HG--
extra : moz-landing-system : lando
* In nsAutoCompleteController, the logic that determines whether the new search is a prefix of the old search is only done in HandleText, i.e., on input, not when the value is set programmatically.
* That logic is a lot more complex in nsAutoCompleteController.
* nsAutoCompleteController autofills in one case where quantumbar doesn't: when completing the "placeholder" string before starting a new search and waiting for the async results (thereby preventing flicker).
* Some nsAutoCompleteController state gets reset each time the awesomebar is focused (see calls to attachController() in the autocomplete binding, which sets the controller's input, which calls ResetInternalState()). That state is important in regard to autofill and the placeholder string. If it's not reset, then the autofill of one search will incorrectly affect the autofill of a later search.
Differential Revision: https://phabricator.services.mozilla.com/D22306
--HG--
rename : browser/components/urlbar/tests/browser/browser_UrlbarInput_autofill.js => browser/components/urlbar/tests/browser/browser_autoFill_caretNotAtEnd.js
extra : moz-landing-system : lando
I like the error message just as well without the class name. In fact, I think
the word "derived" is important to include here, so the message is even a
little better. The stack and line number make it super clear which constructor
we're talking about, so we're not really losing anything.
In Chrome, the error message is "ReferenceError: Must call super constructor in
derived class before accessing 'this' or returning from derived constructor".
Differential Revision: https://phabricator.services.mozilla.com/D23223
--HG--
extra : moz-landing-system : lando
This changes the order of some cleanup operations, harmlessly, to make
initialization and teardown more FIFO.
Differential Revision: https://phabricator.services.mozilla.com/D23222
--HG--
extra : moz-landing-system : lando
Otherwise you see font changes when hovering, which is not really desirable.
Differential Revision: https://phabricator.services.mozilla.com/D24116
--HG--
extra : moz-landing-system : lando
The graph contains some extra things like toolchains, fetches and packaging
tasks that people will almost never want to run on their own. This change gets
them out of the default fuzzy selection interface, and makes it so --full is
needed to schedule them.
Differential Revision: https://phabricator.services.mozilla.com/D24187
--HG--
extra : moz-landing-system : lando