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
We currently report a useful location in error reports when extensions fail to
resolve a promise or call a response callback, but in some slightly
less-than-ideal ways. We currently generate a complete stack and parse its
string value (which is expensive), and then report the caller location as part
of the message, rather than as the error's location and stack.
This patch changes that behavior to store a single SavedStack frame, and to
properly report that as the location of the error.
MozReview-Commit-ID: Jmtf4C1O6pW
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
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
This allows us to avoid a fairly expensive stringification/string allocation
when calling getUniqueId(), which is helpful. It also allows us to avoid
atomizing the ID string when storing it in a Set or Map, which is even more
helpful. And, of course, it makes comparisons faster.
MozReview-Commit-ID: 8wMc6TdhzfY
This gives us performance wins in sevaral areas:
- Creating a structured clone blob of storage data directly from the source
compartment allows us to avoid X-ray and JSON serialization overhead when
storing new values.
- Storing the intermediate StructuredCloneBlob, rather than JSON values,
in-memory saves us additional JSON and structured clone overhead when
passing the values to listeners and API callers, and saves us a fair amount
of memory to boot.
- Serializing storage values before sending them over a message manager allows
us to deserialize them directly into an extension scope on the other side,
saving us a lot of additional structured clone overhead and intermediate
garbage generation.
- Using JSONFile.jsm for storage lets us consolidate multiple storage file
write operations, rather than performing a separate JSON serialization for
each individual storage write.
- Additionally, this paves the way for us to transition to IndexedDB as a
storage backend, with full support for arbitrary structured-clone-compatible
data structures.
MozReview-Commit-ID: JiRE7EFMYxn
This gives us performance wins in sevaral areas:
- Creating a structured clone blob of storage data directly from the source
compartment allows us to avoid X-ray and JSON serialization overhead when
storing new values.
- Storing the intermediate StructuredCloneBlob, rather than JSON values,
in-memory saves us additional JSON and structured clone overhead when
passing the values to listeners and API callers, and saves us a fair amount
of memory to boot.
- Serializing storage values before sending them over a message manager allows
us to deserialize them directly into an extension scope on the other side,
saving us a lot of additional structured clone overhead and intermediate
garbage generation.
- Using JSONFile.jsm for storage lets us consolidate multiple storage file
write operations, rather than performing a separate JSON serialization for
each individual storage write.
- Additionally, this paves the way for us to transition to IndexedDB as a
storage backend, with full support for arbitrary structured-clone-compatible
data structures.
MozReview-Commit-ID: JiRE7EFMYxn
The implementations of browserAction, pageAction, and menu onClick
handlers now stash the current <browser> until we get a reply from
the extension process indicating that the handler has finished running.
We also have to take care to keep that <browser> around even if the
permissions api has to be loaded asynchronously.
MozReview-Commit-ID: BYJaiwdj40u
The implementations of browserAction, pageAction, and menu onClick
handlers now stash the current <browser> until we get a reply from
the extension process indicating that the handler has finished running.
We also have to take care to keep that <browser> around even if the
permissions api has to be loaded asynchronously.
MozReview-Commit-ID: BYJaiwdj40u
Also removes some dead code.
A lot of the code in ExtensionUtils.jsm is not needed in all processes, and a
lot of the rest isn't needed until extension code runs. Most of it winds up
being loaded into all processes way earlier than necessary.
MozReview-Commit-ID: CMRjCPOjRF2
This replaces the JS policy service stubs with a pure C++ version which
directly makes policy decisions based on active WebExtensionPolicy objects.
This is the first step in a larger refactoring, which will remove the
ExtensionManagement module entirely, and replace the current add-on policy
service with direct, non-virtual access to native WebExtensionPolicy objects.
It will also be followed by related changes to migrate the content script and
extension page matching to native code, based on the existing MatchPattern and
WebExtensionPolicy bindings.
MozReview-Commit-ID: 2MpbmXZGiPZ
This is the second step to migrating the policy service to pure native code,
with similar impacts and reasoning to the previous patch.
MozReview-Commit-ID: L5XdPzWNZXM
This is the first step toward migrating the web-accessible URL policy to
purely native code. It should have a noticeable performance improvement on its
own, but the main improvement comes from being able to pass the pattern
objects to the pure C++ policy service.
MozReview-Commit-ID: DHoGLVr8yJ9