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
When passed the `--verbose` flag, `mach xpcshell-test` already prints the
current directory, environment variables, and command used for the test.
However, it prints them in Python syntax. This seems like a good thing to do, as
it's a clear indication of what the test is actually doing. But if one wants to
reproduce a problem by running the xpcshell command directly, it's an
error-prone pain to convert from Python lists of strings to the Bourne shell
syntax.
Fortunately, the Python 2.7 `pipes` module has a function, `pipes.quote`, which
produces properly quoted Unix shell commands, ready to be copied and pasted into
one's terminal.
Unfortunately, the xpcshell tests still clean up the $obj/temp/xpc-plugins-FOO
directory, so this still isn't quite ready to go.
Differential Revision: https://phabricator.services.mozilla.com/D10392
--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
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
Android xpcshell tests run `elfhack -r`, and do so by using an
elfhack binary from an archive downloaded via tooltool (which contains
other things).
Instead, we just put the elfhack binary in the
target.common.tests.tar.gz archive, and make the xpcshell harness
use it from there instead, allowing to pick in-tree changes to elfhack.
Depends on D9623
Differential Revision: https://phabricator.services.mozilla.com/D9624
--HG--
extra : moz-landing-system : lando
The current command line building is hard to follow and make sense of. Let's
just use a single command variable and comment the order it needs.
Depends on D9549
Differential Revision: https://phabricator.services.mozilla.com/D9550
--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
This patch removes linux64-jsdcov from the available builds on taskcluster along with any hacks used to run it. It also removes any 'coverage' entries that were added to skip tests.
Differential Revision: https://phabricator.services.mozilla.com/D7919
--HG--
extra : moz-landing-system : lando
Behavior changes:
- instead of reading the mozconfig file, it now instantiates an instance of the build object.
- safe checking methods are used to access attributes to prevent errors on automation environment.
- better mach command parsing is performed with handler category instead of error-prone argv parsing.
Other changes:
- docstring for testing/xpcshell/runxpcshelltests.py::buildTestList() added and modernized.
- added clause that if length of tests gathered is 0, mach exits with an error code of 1.
Differential Revision: https://phabricator.services.mozilla.com/D7133
--HG--
extra : moz-landing-system : lando
... since AF_INET wouldn't actually use IPv4!
MozReview-Commit-ID: FCf7psawENI
Differential Revision: https://phabricator.services.mozilla.com/D4749
--HG--
extra : moz-landing-system : lando
Set the "network.trr.disable-ECS" pref to false to disable.
MozReview-Commit-ID: GE6L8Vpvuu0
Differential Revision: https://phabricator.services.mozilla.com/D2933
--HG--
extra : moz-landing-system : lando
This will make sure that when running |mach python-test --python 3| locally,
we only run the tests that also run in CI with python 3 (and therefore pass
presumably).
MozReview-Commit-ID: 3OBr9yLSlSq
--HG--
extra : rebase_source : 456340d0ecdddf1078f2b5b4ebb1eddf3813b26a
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.
... and before chasing a cname, check if the address record for that
CNAME is actually in fact already provided in the DNS packet that passed
on the CNAME!
Some existing tests ajusted for this. Two new tests added.
MozReview-Commit-ID: CBMO7N7jMEX
--HG--
extra : rebase_source : 1110a8df6d89fcbb0ad2a35b3762b837ce7a1e18
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
In the section of the response body parser that just skips over the
answer section, the code wrongly assumed there could only be a pointer
at the start, while in fact every label can be made as a pointer. Just
turned out to not be used very often.
MozReview-Commit-ID: 8ZYtlq8HDPw
--HG--
extra : rebase_source : cc790caf36b4d4e77b113f89ed427ee537a539d8
Now that XPT files are not loaded from files at runtime, code for
packaging XPT files can be removed.
This means that a couple of test XPIDL interfaces will get shipped in
builds to users that weren't before, but I don't think that matters
much.
This also puts XPT files into the local objdir for the XPIDL makefile,
instead of dist/bin, because they are no longer part of the
distribution.
MozReview-Commit-ID: 7gWj8KWUun3
--HG--
extra : rebase_source : 65bac47c2cd1a20b3c675a01b44a25a1d2d3ab7a
Since |mach xpcshell-test| was already defaulting to the 'mach' format, this will be a no-op
for most people. For anyone who had:
[test]
format=tbpl
in their machrc file, this will start working for xpcshell tests.
MozReview-Commit-ID: LwIlh0lefN6
--HG--
extra : rebase_source : 5231e18c57e1aa3aacbc6d332127b7c9e2f9111f
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
RFC 1035 section 4.1.1 documents this bit as:
RD - Recursion Desired - this bit may be set in a query and is copied
into the response. If RD is set, it directs the name server to pursue
the query recursively. Recursive query support is optional.
MozReview-Commit-ID: 8iHDgNtA1L1
--HG--
extra : rebase_source : a29010a2894fd00ebfbfb869f5938cf507345a2f
Provides an optional resolver mechanism for Firefox that allows running
together with or instead of the native resolver.
TRR offers resolving of host names using a dedicated DNS-over-HTTPS server
(HTTPS is required, HTTP/2 is preferable).
DNS-over-HTTPS (DOH) allows DNS resolves with enhanced privacy, secure
transfers and improved performance.
To keep the failure rate at a minimum, the TRR system manages a dynamic
persistent blacklist for host names that can't be resolved with DOH but works
with the native resolver. Blacklisted entries will not be retried over DOH for
a couple of days. "localhost" and names in the ".local" TLD will not be
resolved via DOH.
TRR is preffed OFF by default and you need to set a URI for an available DOH
server to be able to use it. Since the URI for DOH is set with a name itself,
it may have to use the native resolver for bootstrapping. (Optionally, the
user can set the IP address of the DOH server in a pref to avoid the required
initial native resolve.)
When TRR starts up, it will first verify that it works by checking a
"confirmation" domain name. This confirmation domain is a pref by default set
to "example.com". TRR will also by default await the captive-portal detection
to raise its green flag before getting activated.
All prefs for TRR are under the "network.trr" hierarchy.
The DNS-over-HTTPS spec: https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-03
MozReview-Commit-ID: GuuU6vjTjlm
--HG--
extra : rebase_source : 53fcca757334090ac05fec540ef29d109d5ceed3
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
This is a new issue that gets linted with flake8 3.5.0. Basically you should
never use a blank except: statement.
This will catch all exceptions, including KeyboardInterrupt and SystemExit
(which is likely not intended). If a catch all is needed, use
`except: Exception`. If you *really* mean to also catch KeyboardInterrupt et
al, use `except: BaseException`.
Of course, being specific is often better than a catch all.
MozReview-Commit-ID: FKx80MLO4RN
--HG--
extra : rebase_source : 7c74a7d0d81f2c984b47aff3a0ee3448b791177b