Webextension-formatted langpacks now store their list of chrome
registry resources in startupData so that those resources can be
registered early in startup.
MozReview-Commit-ID: 80eOiPKLlWu
This prevents prompts occuring in cases where the new permissions are more
specific but still covered by the old permissions.
e.g.:
["<all_urls>"] -> ["<all_urls>", "*://*.example.com"]
["*://*.example.com"] -> ["http://subdomain.example.com"]
MozReview-Commit-ID: B685pJ6kTNa
The current timeout was added to deal with some shutdown deadlocks that were
happining in the wild, but were hard to reproduce locally and therefore
diagnose. It's not clear whether the bulk of those have been fixed, so I'm
reluctant to remove the timeout entirely.
But the current 1s timeout is quite short, and doesn't allow for proper
cleanup in a lot of legitimate cases. The async shutdown service starts to
emit warnings at 10s, so 8s gives us enough time to avoid at least that.
MozReview-Commit-ID: 94zZjYUY8qZ
These getters are checked very rarely, and not at all in most sessions. They
don't justify the overhead of adding lazy getters at startup.
MozReview-Commit-ID: 9XVlLapNJCE
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
For unpacked extensions, loading the locales list adds an appreciable delay to
startup time. For packed extension, the overhead is much lower, but still best
avoided.
MozReview-Commit-ID: 6kicOU78fpZ
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
