AndroidMixin properties are queried by mozharness prior to __init__
completion, so AttributeError is expected and is fairly safe to
ignore, but other exceptions should be reported.
hud.owner can be null in some condition, so we
need to guard the access to hud.owner.target.
Differential Revision: https://phabricator.services.mozilla.com/D9069
--HG--
extra : moz-landing-system : lando
The test is failing because the result of the last
evaluation is received before we expect it. Since we
had a 500ms delay between each promise resolution, it
might happen than the time it takes to execute the
command execedes this delay, making our expected message
order wrong.
Increasing the delay between each Promise resolution seems
to resolve the issue, although it makes the test a lot longer too.
This is why a new test was created to only cover the concurrent
await case.
Differential Revision: https://phabricator.services.mozilla.com/D8698
--HG--
rename : devtools/client/webconsole/test/mochitest/browser_jsterm_await.js => devtools/client/webconsole/test/mochitest/browser_jsterm_await_concurrent.js
extra : moz-landing-system : lando
with the new interpolation rules; r?hiro
The updated tests are intended to cover percent translation when using matrix
decomposition but after introducing the new interpolation rules the initial
rotate() functions will match so the result will differ. This patch updates the
test values so that the result will not change even after introducing the new
interpolation rules.
Depends on D9183
Differential Revision: https://phabricator.services.mozilla.com/D9184
--HG--
extra : moz-landing-system : lando
Show that an Extension is controlling the default notifications permission
Differential Revision: https://phabricator.services.mozilla.com/D5042
--HG--
extra : moz-landing-system : lando
This replaces a bunch of code that inserted separators by hand.
For now I've kept the output mostly the same by forcing the locale to en-US.
But at least now we could consider localizing the output.
The places where the output is different, it's more consistent with the new
code. E.g. printing "-05.55%" (which matches "05.55%") instead of "-5.55%".
--HG--
extra : rebase_source : 7c7161e5ab07e55e514020070bdfa4a774644a53
Creates the nsDocShellLoadState object, which is basically
nsDocShellLoadInfo plus a few extra fields to make it usable as a
single argument to nsDocShell::LoadURI (and eventually
nsDocShell::InternalLoad).
Subframe history handling is a huge logic block in
nsDocShell::LoadURI, which is only used on history loads. This patch
also extracts the logic out into its own function to make the body of
LoadURI clearer.
Differential Revision: https://phabricator.services.mozilla.com/D6944
--HG--
rename : docshell/base/nsDocShellLoadInfo.cpp => docshell/base/nsDocShellLoadState.cpp
rename : docshell/base/nsDocShellLoadInfo.h => docshell/base/nsDocShellLoadState.h
extra : moz-landing-system : lando
The Webrender Pref Experiment is reporting its pref via telemetry and that is
reporting a different value than what the Normandy experiments telemetry
indicates should be being seen.
In Bug 1499552 I added a pref and telemetry reporting in preparation for running
a dummy Pref Experiment to verify that prefs set are reported as set, but I
realised I missed a case; where there's an existing default pref set,
we're only covering the case where that default pref has value false. We're seeing
a ~25% failure rate in the pref reporting. So we should cover the other three cases
in the dummy Pref Experiment, just in case it's one of these four cases that
is failing.
So here I add another dummy pref with a default value of true, and I report that
via telemetry. I rename the pref I added yesterday to make things consistent.
Differential Revision: https://phabricator.services.mozilla.com/D9156
--HG--
extra : moz-landing-system : lando
There is no advantage in making these methods more restrictive on their
parameters than AssignLiteral.
The current implementation of the AppendLiteral overloads for equivalent
char_types is more permissive than AssignLiteral, but comments in the
implementation mention the possible optimization used in AssignLiteral and so
are assuming a similar constant and static storage duration restriction on its
parameter. The optimization may never be implemented, but clients that would
benefit from support for non-constant or non-static parameters are also
expected to be rare, so there is little value in ruling out the optimization
at this stage.
ReplaceLiteral currently uses the AssignLiteral optimization.
Differential Revision: https://phabricator.services.mozilla.com/D8777
--HG--
extra : moz-landing-system : lando
A character array initialized with a list of character literals will not
necessarily have a trailing null-terminator required for AssignLiteral or
trimmed in EqualsLiteral.
Depends on D8775
Differential Revision: https://phabricator.services.mozilla.com/D8951
--HG--
extra : moz-landing-system : lando
Geoff Brown
Andrea Marchesini
Narcis Beleuzu
Brindusan Cristian
Nicolas Chevobbe
Johann Hofmann
Brian Birtles
prathiksha
Nicholas Nethercote
Cosmin Sabou
Noemi Erli
Nick Thomas
arthur.iakab
Kyle Machulis
Chris Pearce
Lee Salzman
ScottDowne
Dennis Schubert
Daniel Holbert
Karl Tomlinson