For static components, I don't intend to allow removing or replacing CID
entries, only contract ID entries. And I would generally prefer, when
restoring overrides of those classes, to not create a new dynamic factory
entry for the contract ID.
We already have the ability to mock components without either of those issues,
but registering a new CID entry for the mock (without unregistering the
original), and then restoring the original by calling `registerFactory` with a
null factory object.
This patch updates our existing mocks to behave that way, and paves the way
for the rest of the patches.
Differential Revision: https://phabricator.services.mozilla.com/D15031
--HG--
extra : rebase_source : 449f37ae8a3cc970e5f864d10e43e88d9e7e4bf6
extra : source : bedaa9c437ad30ea88bdc0e8fc83f4a2e980812e
For static components, I don't intend to allow removing or replacing CID
entries, only contract ID entries. And I would generally prefer, when
restoring overrides of those classes, to not create a new dynamic factory
entry for the contract ID.
We already have the ability to mock components without either of those issues,
but registering a new CID entry for the mock (without unregistering the
original), and then restoring the original by calling `registerFactory` with a
null factory object.
This patch updates our existing mocks to behave that way, and paves the way
for the rest of the patches.
Differential Revision: https://phabricator.services.mozilla.com/D15031
--HG--
extra : rebase_source : 61ef2435d764c2d9daee6a16515eb0efd94a6454
***
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
This commit creates an empty 'base' profile because I wanted to preserve the
ability to apply a pref to all test harnesses on try. Since xpcshell doesn't
share many prefs with the other harnesses, it can't use the common profile.
So adding a pref to 'common' will apply it everywhere except xpcshell. Adding
a pref to 'base' will apply it everywhere including xpcshell. These profiles
are starting to get a bit messy, but I'd like to punt re-organizing them to a
follow-up bug.
Depends on D9716
Differential Revision: https://phabricator.services.mozilla.com/D9717
--HG--
extra : moz-landing-system : lando
This uses nsIPrefService.readUserPrefsFromFile to set preferences from a
user.js passed in via the python harness. This allows us to use the profiles
under testing/profiles like all the other harnesses and will make setting prefs
in xpcshell easier to use and understand.
Differential Revision: https://phabricator.services.mozilla.com/D9716
--HG--
extra : moz-landing-system : lando
This commit creates an empty 'base' profile because I wanted to preserve the
ability to apply a pref to all test harnesses on try. Since xpcshell doesn't
share many prefs with the other harnesses, it can't use the common profile.
So adding a pref to 'common' will apply it everywhere except xpcshell. Adding
a pref to 'base' will apply it everywhere including xpcshell. These profiles
are starting to get a bit messy, but I'd like to punt re-organizing them to a
follow-up bug.
Depends on D9716
Differential Revision: https://phabricator.services.mozilla.com/D9717
--HG--
extra : moz-landing-system : lando
This uses nsIPrefService.readUserPrefsFromFile to set preferences from a
user.js passed in via the python harness. This allows us to use the profiles
under testing/profiles like all the other harnesses and will make setting prefs
in xpcshell easier to use and understand.
Differential Revision: https://phabricator.services.mozilla.com/D9716
--HG--
extra : moz-landing-system : lando
If something goes wrong when setting prefs, that's something we'll want to know
about as it likely means some tests will start to fail.
Differential Revision: https://phabricator.services.mozilla.com/D9549
--HG--
extra : moz-landing-system : lando
These tests were only not connecting due to an implementation detail
of the Push component.
MozReview-Commit-ID: 49JPgsfRxTF
--HG--
extra : rebase_source : 10a9116cbd4ecfbd8071b856bfafa59fe6dcdffc
There are some places where we have a thing which may not even be a node, and
we end up hardcoding the value of DOCUMENT_NODE there, because
"foo.nodeType == foo.DOCUMENT_NODE" will test true if foo is not a node: both
sides will be undefined.
Also fixes existing code which fails the rule.
MozReview-Commit-ID: CkLFgsspGMU
--HG--
extra : rebase_source : 86a43837659aa2ad83a87eab53b7aa8d39ccf55b
In older builds, task functions were allowed to return generators, which were
automatically wrapped into tasks using Task.jsm. This model is no longer
supported, so to prevent it from passing silently, we should check for and
reject uses of the old pattern.
MozReview-Commit-ID: 4cHo7pEqYJn
--HG--
extra : rebase_source : c045550457152a8961f0e76e9489c799dfd0840e
extra : histedit_source : 9d2e14a1ab80a6a099101c256b68102ac34513d8
The directory service caches certain directory entries, or has them set by
other callers using `.set()`. When we try to override those directories with
custom providers, the cached value still takes precedence.
It might make more sense to just store the directory entry values directly in
the directory service's hash, but this patch just takes the less obtrusive
path of clearing cached values for keys that we override.
This patch also fixes the few instances where add-on manager tests leave files
in the global temporary directory which are now caught by the shutdown
assertions.
MozReview-Commit-ID: Jq92TngLO1L
--HG--
extra : rebase_source : 76eb1f02882bd10151115bf1e934a38d313d0cb2
extra : histedit_source : df0293e06e4357080318beb92c7a1e00766a8799
The xpcshell harness tries to filter out head.js stack frames when reporting
errors. When it fails, it tends to report strange error locations, with the
name of a unit test file, but the line number of a line in a head file. This
changes the filter to match more common head.js files, such as head_addons.js.
MozReview-Commit-ID: FASWNSR0Noc
--HG--
extra : rebase_source : ad1fa30c8357ee77c08b4df0acd665a7e625227e
extra : histedit_source : 7dde0025fcc8ba3a86258c7649578966e5cdca53%2C975a6db069f5e34e61cc0f6cbebb0f56ffab816c
The xpcshell harness expects to catch the Cr result codes that it throws, but
it often fails when an assertion is used in asynchronous code. That results in
a raw numeric error code being reported, with no location information
available to figure out why or where the test is failing.
Throwing an actual Exception object maintains location information for use
when the error is reported.
MozReview-Commit-ID: InuytWhDxBP
--HG--
extra : rebase_source : 79692462549fc0240459000b0b490d046f473b67
extra : histedit_source : 83259c3bb633fd046acc8230ee40e88dd0214a4c%2Cf688ffe04de88a2d5dae3c03af240e90a1f2e398
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
