Looks like spoofing the event is not enough as GeckoView intialization code
(indirectly) uses the profile folder.
We also catch exceptions coming from the init code and throw them appropriately
so we don't ignore errors during initialization.
Differential Revision: https://phabricator.services.mozilla.com/D109797
This variable can be used by platforms to modify the current directory, useful
on Android as the process where the xpcshell test runs does not really have the
concept of CWD.
Differential Revision: https://phabricator.services.mozilla.com/D106207
This variable can be used by platforms to modify the current directory, useful
on Android as the process where the xpcshell test runs does not really have the
concept of CWD.
Differential Revision: https://phabricator.services.mozilla.com/D106207
We always used to pause when "attaching" the thread actor.
We ought to call ThreadActor's attach method first before using it.
And this method do various things:
* Initialize the Debugger API, enable it, register various listeners, so that breakpoint can work,
* Pause the current thread by starting a nested event loop
So that we also ought to resume the thread, by calling ThreadActor's resume right after attach.
Otherwise the page would be paused as soon as we open the DevTools.
Which sounds like something we might have wanted a very long time ago.
But sounds like pure legacy behavior from today's perspective.
Differential Revision: https://phabricator.services.mozilla.com/D99919
This preference is currently only used when running Windows XPCShell
tests in order to disable IPv6 resolution for "localhost". However, this
does not seem to be needed anymore and actually breaks the expectation
that "localhost" resolves to IPv4 and IPv6 loopback addresses
(see bugs 1673315, 1673364, 1220810).
Differential Revision: https://phabricator.services.mozilla.com/D94986
This allows generic code, like a testing JSM, to do clean up when a
test completes, in a way that will work in different test suites.
Differential Revision: https://phabricator.services.mozilla.com/D50648
--HG--
extra : moz-landing-system : lando
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