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
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
"Bound" is the term used in the C++ standard to describe the number of
elements in an array.
EqualsLiteral has no opportunity to optimize for constant and static storage
duration parameters.
Depends on D8773
Differential Revision: https://phabricator.services.mozilla.com/D8774
--HG--
extra : moz-landing-system : lando
There is no advantage in AssignASCII() for char, and AssignASCII() does not
exist for char16_t array and char_type. Similarly for ReplaceASCII and
AppendASCII. This AssignLiteral() overload already says it is not only for
ASCII.
Depends on D8771
Differential Revision: https://phabricator.services.mozilla.com/D8773
--HG--
extra : moz-landing-system : lando
Since https://hg.mozilla.org/mozilla-central/rev/9db7cf4cc385#l13.44 the type
system always excludes calls with character pointers and so there is no need
to mention this in the comment.
The comment for the 8-bit to 16-bit AssignLiteral overload is modified a
little to use "char" instead of "character" so as not to imply that anything
other than 8-bit char parameters may be provided to that overload.
The ReplaceLiteral and InsertLiteral comments are adjusted to use "character"
instead of "char" so as not to imply that the method or comment is limited to
8-bit char parameters.
Differential Revision: https://phabricator.services.mozilla.com/D8770
--HG--
extra : moz-landing-system : lando
This patch also updates the expectations in the mochitest test_flex_items.html.
Before this commit, the test (incorrectly) expected the mainBaseSize API to
return some items' *final sizes*, because that's what our implementation did
return, up until now. As of this patch, that API will now return the item's
actual flex base size, which means the text expectations need to change.
I'm also adding a new flex item to the test, to exercise a formerly-untested
scenario. And to accommodate this new item, I'm also doubling the width of
the flex container to be sure there's plenty of space.
Differential Revision: https://phabricator.services.mozilla.com/D8476
--HG--
extra : moz-landing-system : lando
The majority of the XUL broadcaster logic is moved out of XULDocument and
into a separate class (XULBroadcastManager). The hookup points for when
listeners need to be created and listeners need to be notified is now
handled by the XULElement itself and nsDocument. To avoid any overhead,
the XULBroadcastManager is only ever created when a document uses a
listener.
The new approach does have the disadvantage that broadcasting can now only
work with XULElements, but going forward we'd like to discontinue this
feature and rely on MutationObservers to implement similar things.
One test had to be modified to use XUL elements instead of HTML elements
because of the reason noted above.
Differential Revision: https://phabricator.services.mozilla.com/D8888
--HG--
extra : moz-landing-system : lando
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
The known web element cache in the WebDriver test client, or
webdriver.Session._element_cache, is used only to avoid constructing
new webdriver.Element instances of the same web element and serves
no practical purpose beyond that
Since this client is intended for testing purposes, we would like
to be able to construct duplicate webdriver.Element instances,
so that e.g. fake elements can be constructed and send to the remote end.
Depends on D9127
Differential Revision: https://phabricator.services.mozilla.com/D8855
--HG--
extra : moz-landing-system : lando
The Python "is" operator tests object identity, but the tests should
rely on the webdriver.Element equality implementation, __eq__.
Differential Revision: https://phabricator.services.mozilla.com/D9127
--HG--
extra : moz-landing-system : lando
Originally landed as changeset 8793e332890e via bug 1433905 the
patch caused a regression because GetExitCodeProcess() returns
0 for an inside of Firefox restarted process.
It can be relanded once the process id of the job object can
successfully be tracked.
Differential Revision: https://phabricator.services.mozilla.com/D9020
--HG--
extra : moz-landing-system : lando
Brindusan Cristian
Nicolas Chevobbe
Narcis Beleuzu
Johann Hofmann
Brian Birtles
prathiksha
ScottDowne
Dennis Schubert
Daniel Holbert
Karl Tomlinson
Matthew Noorenberghe
Cosmin Sabou
Brendan Dahl
Ryan VanderMeulen
arthur.iakab
Nick Thomas
Kyle Machulis
Chris Pearce
Lee Salzman
Mark Striemer
Henrik Skupin
Andreas Tolfsen