Report when recipes don't match the filter. Report when Jexl filters
themselves fail, with an added test.
The existing test for remote-settings usage had a bug, so fix that
too.
Depends on D22017
Differential Revision: https://phabricator.services.mozilla.com/D22018
--HG--
extra : moz-landing-system : lando
Because the mock no longer checks whether the format of events is
correct, check the events that Telemetry actually records, in order to
make sure we conform to the event schema.
Some uses check that *no* calls were made to the stub. Although this
is technically still valid (because we don't care about the format of
events in this case), convert even these to check events for
consistency.
TelemetryTestUtils.assertEvents doesn't allow us to pass a message,
but most of these messages don't add anything useful and at least one
is just wrong so it's not a big loss.
Depends on D19540
Differential Revision: https://phabricator.services.mozilla.com/D19831
--HG--
extra : moz-landing-system : lando
This also means we no longer have direct access to the event schema,
so rely on Telemetry to throw when we send an invalid event.
Differential Revision: https://phabricator.services.mozilla.com/D19540
--HG--
extra : moz-landing-system : lando
We now disallow the % sign in the hostname of a URL.
If the app.normandy.api_url pref isn't set explicitly, it'll remain the default set in xpcshell/user.js: https://%(server)s/selfsupport-dummy/. As you can see, this one has a % sign in it; and the test will fail.
Otherwise, the error we catch is not a NormandyApi.InvalidSignatureError, but NS_ERROR_MALFORMED_URI.
Differential Revision: https://phabricator.services.mozilla.com/D16695
--HG--
extra : moz-landing-system : lando
AddonManagergetInstallForURL() has a number of optional arguments, most
of which are passed infrequently. Convert them from positional arguments
to a single options object.
Differential Revision: https://phabricator.services.mozilla.com/D18475
--HG--
extra : rebase_source : 503c09b54fab90cefe69286b05def43ef70074df
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
I think this should have been here before but it wasn't.
To make it easier to distinguish recipes generated by
preferenceStudyFactory, give them a unique name with the unused
_preferenceStudyFactoryId.
Depends on D13574
Differential Revision: https://phabricator.services.mozilla.com/D13575
--HG--
extra : moz-landing-system : lando
Reading test logs is a bit baffling because all tests are called
"wrappedTestFunction". Try to imitate a Pythonic decorator and
make the returned function have the same name as the old one.
Function.prototype.name is a readonly property, but MDN says you can
set a function's name using Object.defineProperty, so that's what we
do.
Depends on D13572
Differential Revision: https://phabricator.services.mozilla.com/D13573
--HG--
extra : moz-landing-system : lando
Having _preExecute be called in the constructor makes it hard to test
it, but because it's a lifecycle hook that subclasses are intended to
override, testing it is very natural.
While we're here, move the initialization of AddonStudyAction from
_preExecute to the constructor, since it doesn't really make sense for
AddonStudyAction to be constructed without all members initialized.
Differential Revision: https://phabricator.services.mozilla.com/D13572
--HG--
extra : moz-landing-system : lando
Instead of obtaining the recipes from the Normandy server, obtain them from RemoteSettings
Differential Revision: https://phabricator.services.mozilla.com/D11490
--HG--
extra : moz-landing-system : lando
nsIPrefBranch.deleteBranch doesn't work as documented when the preference's
default value was set very early after Firefox has started, such as when
Normandy sets startup branches. This is filed as bug 1505941. In order to work
around this problem, this patch makes Normandy never use deleteBranch, except
in tests where it is safe to do so.
With this patch, an experiment that is run on the default branch for a
preference that does not have a default value in the tree cannot be promptly
unenrolled, instead we must wait until the preference is naturally cleared when
Firefox restarts. This is better than never unenrolling though.
Differential Revision: https://phabricator.services.mozilla.com/D11383
--HG--
extra : moz-landing-system : lando
As part of the conversion, support for notificationsHidden and children that are not notifications is also removed.
Differential Revision: https://phabricator.services.mozilla.com/D10894
--HG--
rename : toolkit/content/widgets/notification.xml => toolkit/content/widgets/notificationbox.js
extra : rebase_source : 36a5412e1e9a9dc591fd486d1123c1f763a6f173
I suspect that the root cause of bug 1502182 is that we try open a database
connection before the old one is fully closed. Instead of dealing with
complicatedasync bookkeeping to make sure this doesn't happen, this patch
simply never closes the database connection. I don't think any of the
benefits of closing IndexedDB databases apply to Normandy, and it isn't
a significant cost to simply keep them open.
Additionally, the patch distinguishes between readonly and readwrite
transactions with the database. This was originally done to try and fix
the bug. When it didn't help, I decided to leave the change in because
it is a beneficial change anyways.
Differential Revision: https://phabricator.services.mozilla.com/D10629
--HG--
extra : moz-landing-system : lando
I suspect that the root cause of bug 1502182 is that we try to create multiple
readwrite stores on a given database at the same time, and that we don't wait
for databases to fully close before reopening them. I don't think any of the
benefits of closing IndexedDB databases apply to Normandy, and I don't think it
is a significant cost to simply keep them open.
Differential Revision: https://phabricator.services.mozilla.com/D10629
--HG--
extra : moz-landing-system : lando
