***
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
Normalize errors thrown by extension API implementations in content
processes to ensure that extension code can read the error message
if the error is an instance of ExtensionUtils.ExtensionError.
This code path is triggered in browser_ext_menus_replace.js and
browser_ext_menus_replace_menu_permissions.js.
Depends on D6625
Differential Revision: https://phabricator.services.mozilla.com/D6626
--HG--
extra : moz-landing-system : lando
- Register pagehide/pageshow events in the system group and ignore
synthetic events to avoid interference from web pages.
- Remove unused docShell member.
- Fix memory leak in bfcached windows, by ensuring that BaseContext
instances can be GC'd when an extension is unloaded, even if the
context is associated with a page in the bfcache.
- Ensure that context.contentWindow and context.active always have an
accurate value.
The latter is achieved by moving all contentWindow tracking logic in a
new helper class "InnerWindowReference".
Differential Revision: https://phabricator.services.mozilla.com/D4072
--HG--
extra : moz-landing-system : lando
- Register pagehide/pageshow events in the system group and ignore
synthetic events to avoid interference from web pages.
- Remove unused docShell member.
- Fix memory leak in bfcached windows, by ensuring that BaseContext
instances can be GC'd when an extension is unloaded, even if the
context is associated with a page in the bfcache.
- Ensure that context.contentWindow and context.active always have an
accurate value.
The latter is achieved by moving all contentWindow tracking logic in a
new helper class "InnerWindowReference".
Differential Revision: https://phabricator.services.mozilla.com/D4072
--HG--
extra : moz-landing-system : lando
- Register pagehide/pageshow events in the system group and ignore
synthetic events to avoid interference from web pages.
- Remove unused docShell member.
- Fix memory leak in bfcached windows, by ensuring that BaseContext
instances can be GC'd when an extension is unloaded, even if the
context is associated with a page in the bfcache.
- Ensure that context.contentWindow and context.active always have an
accurate value.
The latter is achieved by moving all contentWindow tracking logic in a
new helper class "InnerWindowReference".
Differential Revision: https://phabricator.services.mozilla.com/D4072
--HG--
extra : moz-landing-system : lando
I generally tried to preserve the behavior of consumers where they treated an
exception from getInterface(Ci.nsIContentFrameMessageManager) as a signal to use
some sort of fallback.
I did change the behavior of consumers that walked up to the root same-type
docshell before getting the message manager to just get it directly from the
docshell they have. Please review those parts carefully, and let me know if you
want me to ask some subject area experts to review those.
I generally tried to preserve the behavior of consumers where they treated an
exception from getInterface(Ci.nsIContentFrameMessageManager) as a signal to use
some sort of fallback.
I did change the behavior of consumers that walked up to the root same-type
docshell before getting the message manager to just get it directly from the
docshell they have. Please review those parts carefully, and let me know if you
want me to ask some subject area experts to review those.
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
When a background page has a messaging listener but the background page
is started in response to something other than an extension message, we
were missing the background "startup" event. Fix that by setting up the
listener earlier.
MozReview-Commit-ID: Cr58EyCoY6W
--HG--
extra : rebase_source : 0d309e01be35e2ef7ab5e489726d0191571ca371
- Un-lazify the startup promises in ext-toolkit.js since the
manifest background property is handled asynchronously, so it
races with startup and can miss the relevant events if it
loses the race.
- Ensure that persistent events don't cause breakage when the
background-delayed-startup preference is set to false.
- Add a wakeup() method to the fire object provided to primed
listeners. This method returns a Promise that resolves when
the extension background page has started. Events that need to
do some work in the context of the extension can wait on the
result of wakeup(), then continue processing after the background
page is started, using fire.[a?]sync as normal.
MozReview-Commit-ID: HiYOguVdEQK
--HG--
extra : rebase_source : e3103fc53369a7665fd071598e0285c4705cf791
extra : source : 50a1ddd35664449c908ea326b364d367871e78a9
These issues were previously ignored due to the nature of our global import
rules. They need to be fixed before that rule can be updated.
MozReview-Commit-ID: DCChktTc5TW
--HG--
extra : rebase_source : cffb1c9762191c579d1397c8169e6e7635d229da
extra : histedit_source : dea59ddd2daaae52069c5faceae9149a4f08dd73
- Un-lazify the startup promises in ext-toolkit.js since the
manifest background property is handled asynchronously, so it
races with startup and can miss the relevant events if it
loses the race.
- Ensure that persistent events don't cause breakage when the
background-delayed-startup preference is set to false.
- Add a wakeup() method to the fire object provided to primed
listeners. This method returns a Promise that resolves when
the extension background page has started. Events that need to
do some work in the context of the extension can wait on the
result of wakeup(), then continue processing after the background
page is started, using fire.[a?]sync as normal.
MozReview-Commit-ID: HiYOguVdEQK
--HG--
extra : rebase_source : 249235553d591fec2110c213ab8b4637fe1aaf08
As we add more behaviors to EventManager, the signature of the constructor
is going to get really clumsy. Head that off by converting it to take a
general parameters object.
This introduces a compatibility problem for existing webextension experiments,
put in a backward-compatibility shim for now.
MozReview-Commit-ID: 72QDfiwRm5j
--HG--
extra : rebase_source : 31c3fd561f373a5d75c4336de830aa5a2abfe797
Currently, when we create an error object at the end of an aysnc operation, we
only get a useful caller location if async stacks are enabled.
This patch changes our behavior to use the saved caller location we've already
stored when creating an Error object based on a plain string message.
MozReview-Commit-ID: DDO0lAUHYRO
--HG--
extra : rebase_source : 995ea3c6de26b616a6cef483b271e222bb2aaf6e
When we report errors generated by async API operations, they are currently
not tied to any relevant extension source location. Instead, the locations in
the error reports point to the location in the framework code which reported
the error, which makes things extremely difficult to diagnose.
This change saves the extension caller location at the beginning of async API
operations, and adds it to the error reports genearted by that operation. This
should give extension developers a useful starting point for debugging them.
MozReview-Commit-ID: AkknkKEosFt
--HG--
extra : rebase_source : 598a232430a36f15ffd1bd7fa8b8ee9733927c12
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 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
This is necessary before we enable the ESLint rule to require using
ChromeUtils for module imports rather than older methods.
MozReview-Commit-ID: mKqByUS0o2
--HG--
extra : rebase_source : d4b856aac7ff7eddc37cbf591c4e6522c45453e2
extra : histedit_source : 1ca2b6031e480fb44a15991241901224acc9e52f