For now this defers to the existing APIs and determines the correct dataset from a global flag.
Differential Revision: https://phabricator.services.mozilla.com/D8858
--HG--
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.
So add reporting for two dummy prefs, one with a default value, and one
without. We intend to push out Normandy rules to report these prefs to
double-check that Normandy is working as expected.
Differential Revision: https://phabricator.services.mozilla.com/D8926
--HG--
extra : moz-landing-system : lando
This interface is only used for a few testing functions. Just move
them to Cu.
Differential Revision: https://phabricator.services.mozilla.com/D8168
--HG--
extra : moz-landing-system : lando
The autoplay shield-study which will run on Release 63 needs one of these data and we also want to analysis other data in order to improve the user experience of blocking-autoplay.
Differential Revision: https://phabricator.services.mozilla.com/D9014
--HG--
extra : moz-landing-system : lando
Ensure the webcompat report addon is disabled upon load, if extensions.webcompat-reporter.enabled=false, take two
Differential Revision: https://phabricator.services.mozilla.com/D8678
--HG--
extra : moz-landing-system : lando
Right now, we have no idea how often an origin may offer us multiple alt-svc options. As we are considering racing multiple alt-svc connections (if they're available), it would be good to know how often we actually have (or would have, were we to store them) multiple options available. It would also be good to know how often an origin may change the target of its alt-svc mapping (even if there is only one target), as changes in target may make it useful to store/race multiple targets, as well.
Differential Revision: https://phabricator.services.mozilla.com/D8878
--HG--
extra : moz-landing-system : lando
Delaying the loading of some OS.Constants.Path members to reduce startup
IO is breaking the test_system_delay_update.js test, because it leaves
tmpaddon-* files in the user's temp directory. As far as I can tell this
is okay (please correct me if wrong) - but the error in AddonTestUtils
was being avoided because the OS.Constants.Path.tmpDir value was being
read before we override TmpD for the test. So now we are leaving them
to be ignored in the TmpD directory we specified, rather than leaving
them to be ignored in the user's temp directory.
Depends on D6080
Differential Revision: https://phabricator.services.mozilla.com/D6081
--HG--
extra : moz-landing-system : lando
In bug 1388134 we're lazifying some members of OS.Constants.Path
to avoid the extra startup IO. userApplicationDataDir is ripe for
being made lazy, except it's read early in CrashManager.jsm. This
defers that until it's used, and adjusts the affected tests.
Depends on D6079
Differential Revision: https://phabricator.services.mozilla.com/D6080
--HG--
extra : moz-landing-system : lando
These calls to GetPathToSpecialDir are performing some unnecessary IO
during early startup which we'd like to defer. Simply adding the
required ones to the list in osfile_async_front.jsm should mostly get
us there.
Differential Revision: https://phabricator.services.mozilla.com/D6079
--HG--
extra : moz-landing-system : lando
When defaulting to a null triggering principal, these tests would fail
when loaded remotely. This patch adds explicit system triggering
principal to the loadURI calls.
Differential Revision: https://phabricator.services.mozilla.com/D8461
--HG--
extra : moz-landing-system : lando
nsIWebNavigation.loadURI actually has an optional triggering principal
parameter that RemoteWebNavigation hasn't implemented. This patch adds
the extra parameter to RemoteWebNavigation's implementation so
triggering principals are passed properly when loadURI is called with
a triggering principal.
Differential Revision: https://phabricator.services.mozilla.com/D8460
--HG--
extra : moz-landing-system : lando
RemoteWebNavigation is expected to pass a serialized principal, so the
default null principal should be serialized as well.
Differential Revision: https://phabricator.services.mozilla.com/D7784
--HG--
extra : moz-landing-system : lando