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
"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
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
GeckoResult can now be created on a thread with no Looper present.
You can use `then` as before after creating a derived GeckoResult
with a Handler via `withHandler`, or poll for the value via
the new `poll` method.
Differential Revision: https://phabricator.services.mozilla.com/D7896
--HG--
extra : moz-landing-system : lando
This commit reduces the appendTreeElements2's treeline arguments from 3 to 2,
and makes the code easier to understand. It's also more efficient, because a
concatenation that used to be repeated for every child of a node is now done
once for all children.
This commit also shortens treeline variable names, because there are a lot of
them and they're easier to read when short.
--HG--
extra : rebase_source : 0fa942468b8ddc23506759b2040266d0c60ade14
They're easier to read than \uXXXX escapes, and there's no reason to stick to
ASCII in the source code.
--HG--
extra : rebase_source : c3412c6a4060de6ea007b6758d1d9f2663efa6be
Have embedders send DOM keys to servo and use a strongly typed KeyboardEvent
from the W3C UI Events spec. All keyboard handling now uses the new types.
Introduce a ShortcutMatcher to recognize key bindings. Shortcuts are now
recognized in a uniform way.
Updated the winit port.
Updated webdriver integration.
part of #20331
This cherry-picks part of servo/servo#21881.
Transitions are still broken, but I found these messages more helpful than the
previous ones when diagnosing problems.
This cherry-picks part of servo/servo#20757.
The last caller who used was #14418, which did fix a problem but introduced
multiple. In particular, now transitions don't get expired ever, until they
finish running of course.
That is not ok, given you can have something that the user can trigger to change
the style (hi, :hover, for example), and right now that triggers new
transitions, getting this into a really funny state.
I should give fixing this a shot, but it's non-trivial at all.
This cherry-picks part of servo/servo#20757.
This was done that way just because Servo didn't support the `all` property at
the time.
We should do it this way and optimize it if it's slow. Though I suspect that
most of stuff doesn't actually need to be inherited, my patch at bug 1498943
should make it much faster than what it would otherwise be.
This cherry-picks servo/servo#21946.
Also remove the default selectors for LightweightThemes since we capture the union of all regions and we can leave it up to the other used configuration to know which region is relevant. The whole navigator-toolbox isn't always relavant for LightweightThemes changes since they also affect panels and other widgets.
Differential Revision: https://phabricator.services.mozilla.com/D8815
--HG--
extra : rebase_source : 124ffb5493903fdbbe85d0181b10649d611ddc76
extra : amend_source : c151c8a48a8fb25b3aafc217c293835ab443fa54
Also require basicCardPage has a selectedStateKey
--HG--
rename : browser/components/payments/test/browser/browser_payments_onboarding_wizard.js => browser/components/payments/test/browser/browser_onboarding_wizard.js
extra : rebase_source : f73b3b3f0a5c5ec94ffdbf722f4887097d05d97d
In the current code there are 3 main issues:
1. nsFileStream is not really thread-safe. There is nothing to protect the
internal members and we see crashes.
2. nsPipeInputStream doesn't implement ::Seek() method and that caused issues
in devtools when a nsHttpChannel sends POST data using a pipe. In order to fix
this, bug 1494176 added a check in nsHttpChannel: if the stream doesn't
implement ::Seek(), let's clone it. This was an hack around nsPipeInputStream,
and it's bad.
3. When nsHttpChannel sends POST data using a file stream, nsFileStream does
I/O on main-thread because of the issue 2. Plus, ::Seek() is called on the
main-thread causing issue 1.
Note that nsPipeInputStream implements only ::Tell(), of the nsISeekableStream
methods. It doesn't implement ::Seek() and it doesn't implement ::SetEOF().
With this patch I want to fix point 2 and point 3 (and consequentially issue 1
- but we need a separate fix for it - follow up). The patch does:
1. it splits nsISeekableStream in 2 interfaces: nsITellableStream and
nsISeekableStream.
2. nsPipeInputStream implements only nsITellableStream. Doing this, we don't
need the ::Seek() check for point 2 in nsHttpChannel: a simple QI check is
enough.
3. Because we don't call ::Seek() in nsHttpChannel, nsFileStream doesn't do I/O
on the main-thread, and we don't crash doing so.