Reading the extension permissions DB at startup takes several hundred
milliseconds, largely from the overhead of initializing OS.File. We can avoid
that somewhat by using the stream APIs to read the files, and beginning the
read very early. But the eager initialization gets complicated, and we still
add extra IO to startup.
After this change, the permissions JSON file still remains the primary source
of truth, but the state as of the last session is cached in the volatile
extension startup cache to decrease the overhead of reading it at startup.
MozReview-Commit-ID: HGDt5kSsdzX
IndexedDB helped where we needed to decrease main thread CPU, but it also took
so long to inialize during startup (over 500ms on a fast machine) that it
delayed extension startup more than was acceptable.
Using a structured clone flat file solves the same issues that IndexedDB did,
but with much less startup overhead.
MozReview-Commit-ID: 1Of7uxKCfkg
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 code that saves the pending browser across an asynchronous
API load was accidentally broken as a result of some overzelous
cleanup. Fix it here.
MozReview-Commit-ID: 3ED95YJAHL2
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
This avoids an issue described in https://github.com/mozilla-services/screenshots/issues/3027 Bug 1372750 and Bug 1373749 where a cached version of Screenshot's manifest.json is retained after upgrade
r?aswan
MozReview-Commit-ID: 9RMKTFN1ugI
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 change prepare the WebExtensions internals to the changes applied to the
addon debugging facilities in the other patches from this queue.
In ExtensionParent.jsm, a HiddenXULWindow helper class has been refactored out
of the HiddenExtensionPage and then reused by both HiddenExtensionPage and
the new DebugUtils object.
The DebugUtils object provides the utility methods used by the
devtools actors related to the addon debugging, which are used to retrieve
an "extension process browser XUL element" (a XUL browser element that has been
configured by DebugUtils to be used to connect the devtools parent
actor to the process where the target extension is running), and then release it
when it is not needed anymore (because the developer toolbox has been closed and
all the devtools actors destroyed).
The DebugUtils object used the HiddenXULWindow class to lazily create
an hidden XUL window to contain the "extension process browser XUL elements"
described above (and the HiddenXULWindow istance is then destroyed when there
is no devtools actor that is using it anymore).
MozReview-Commit-ID: 31RYQk1DMvE
This change prepare the WebExtensions internals to the changes applied to the
addon debugging facilities in the other patches from this queue.
In ExtensionParent.jsm, a HiddenXULWindow helper class has been refactored out
of the HiddenExtensionPage and then reused by both HiddenExtensionPage and
the new DebugUtils object.
The DebugUtils object provides the utility methods used by the
devtools actors related to the addon debugging, which are used to retrieve
an "extension process browser XUL element" (a XUL browser element that has been
configured by DebugUtils to be used to connect the devtools parent
actor to the process where the target extension is running), and then release it
when it is not needed anymore (because the developer toolbox has been closed and
all the devtools actors destroyed).
The DebugUtils object used the HiddenXULWindow class to lazily create
an hidden XUL window to contain the "extension process browser XUL elements"
described above (and the HiddenXULWindow istance is then destroyed when there
is no devtools actor that is using it anymore).
MozReview-Commit-ID: 31RYQk1DMvE
