Since base-loader's job is to handle this kind of thing, and it already
requires a special case to populate the descriptor anyway, so it seems a lot
easier to provide this as builtin optional feature of base-loader.
Differential Revision: https://phabricator.services.mozilla.com/D67979
--HG--
extra : moz-landing-system : lando
This patch was generated with the script d2bbd6c459/no-this-property-assign.js
using the following command:
cp .gitignore .rgignore && rg -l -g '*.jsm' '' devtools | jscodeshift --stdin --transform ~/Code/jsm-rewrites/no-this-property-assign.js && ./mach eslint --outgoing --fix
There's also a manual fixup in Loader.jsm from const to var for a couple exports.
Differential Revision: https://phabricator.services.mozilla.com/D60030
--HG--
extra : moz-landing-system : lando
We used to have another provider which would load module via file:// URI,
directly from the disk. But the progress on artifact builds and ./mach build faster
made this obsolete and has been removed a long time ago.
We still have a lot of abstraction to support this non-existent feature.
Differential Revision: https://phabricator.services.mozilla.com/D38284
--HG--
extra : moz-landing-system : lando
The rest was legacy code to support old xul add-ons.
All mozilla-central code used to be refactored, but a few places
were still using the old codepaths.
Differential Revision: https://phabricator.services.mozilla.com/D38283
--HG--
extra : moz-landing-system : lando
The performance profiler pop-up menu wants to be near DevTools, but work
without the complete DevTools initialization. This patch ensure that
any calls to lazyRequireGetter properly initialize the provider.
Differential Revision: https://phabricator.services.mozilla.com/D31628
--HG--
extra : moz-landing-system : lando
***
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
If the packet contains a function or anything that StructureClone doesn't support,
Message manager is going to stringify and parse the packet via JSON API.
This can be a performance issue as it will duplicate the object.
MozReview-Commit-ID: EZC1BU1Ps7Y
--HG--
extra : rebase_source : 8a3ca08724bac26032602c88c4f3b4271dadb359
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
MozReview-Commit-ID: E2dNIMoa2wz
Also get rid of shared global blocklist as this isn't used by DevTools.
--HG--
extra : rebase_source : 99522f4e804e59a233f51c4710645ec24de9eb2e
This file is now only loaded as a JSM.
Expose symbols directly instead of putting them on `Loader` symbol.
No longer exports it as a fake 'toolkit/loader' module and always import it as JSM.
MozReview-Commit-ID: 6J3IxHpk9ct
--HG--
extra : rebase_source : f6ef6aef6d8682f18950a9b22d259347644250f2
DevTools should not execute any code on the browser startup. Loading preferences takes
a non negligeable time and should be deferred to the devtools initialization.
For all devtools entry points, Loader.jsm is always loaded first, so it is safe to
load the preferences here.
MozReview-Commit-ID: Hg4VBj2LqPo
--HG--
extra : rebase_source : 86bfef7e13ecf52b9b8c761fbf7352af42a6bced