Open Bug 1370658 Opened 4 years ago Updated 4 years ago
.manager .add Bootstrapped Manifest Location() can do main thread IO at startup
https://searchfox.org/mozilla-central/rev/d441cb24482c2e5448accaf07379445059937080/toolkit/mozapps/extensions/internal/XPIProvider.jsm#4376 https://perfht.ml/2rRILXj Note that this call is visible in the profile <https://searchfox.org/mozilla-central/source/xpcom/components/nsComponentManager.cpp#1909> but the nsComponentManagerImpl::AddBootstrappedManifestLocation() frame itself is for some reason invisible.
Hey kmag, how much of this was covered by bug 1363482? It looks like this should be WFM now, but I don't want to jump the gun on that. Giving it [fxperf:p3] for now to at least get it out of triage.
Whiteboard: [fxperf] → [fxperf:p3]
(In reply to Doug Thayer [:dthayer] from comment #1) > Hey kmag, how much of this was covered by bug 1363482? It looks like this > should be WFM now, but I don't want to jump the gun on that. Unfortunately none of it was covered by bug 1363482. It would help with system add-ons if they were bundled in OmniJar, but they're currently not. And in unpacked local builds, where they're loaded from the filesystem. In release builds, for the moment anyway, it only helps with the handful of manifests that we bundle in omni.ja. At this point, though, we should really just stop loading chrome manifests from bootstrapped extensions. Our system extensions can be updated to register things without them, and no other extensions need them.
You need to log in before you can comment on or make changes to this bug.