1370658 - Components.manager.addBootstrappedManifestLocation() can do main thread IO at startup

Status: NEW

(Toolkit :: Add-ons Manager, enhancement, P3)

Description

[(no longer active)]

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.

Comment 1

[Doug Thayer [:dthayer] (he/him)]

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.

Comment 2

[Kris Maglione [:kmag]]

(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.

Comment 3

[:Gijs (he/him)]

Florian, do we have any kind of telemetry or BHR input or other data to help establish the perf importance of this ticket?

Comment 4

[:Gijs (he/him)]

Accidentally got the dependency relation the wrong way around.