Both GMPProvider.jsm and ExtensionParent.jsm import osfile.jsm during startup in order to do path manipulations. Due to bug 1408729 this is much more expensive than it needs to be, but we can probably get away without osfile during startup.

fxperf:p2 since it's startup. Andrew, are you actively working on this or is it just assigned for later?

I'm intending to do it during the 67 cycle, but if somebody is eager to do it right now, I'm happy to hand it off...

This turns out to be trickier than I thought. Getting rid of eager imports from GMPProvider.jsm and ExtensionParent.jsm is feasible but there is this that I'm not sure how to avoid:
https://searchfox.org/mozilla-central/rev/00c0d068ece99717bea7475f7dc07e61f7f35984/toolkit/mozapps/extensions/internal/XPIProvider.jsm#652-659

Even if we get rid of all the imports from the addon manager, we also have:
https://searchfox.org/mozilla-central/rev/00c0d068ece99717bea7475f7dc07e61f7f35984/browser/components/sessionstore/SessionWorker.jsm
https://searchfox.org/mozilla-central/rev/00c0d068ece99717bea7475f7dc07e61f7f35984/toolkit/components/thumbnails/PageThumbsWorker.js#16

Bug 1231711 would probably help.

(In reply to Andrew Swan [:aswan] from comment #3)

This turns out to be trickier than I thought. Getting rid of eager imports from GMPProvider.jsm and ExtensionParent.jsm is feasible but there is this that I'm not sure how to avoid:
https://searchfox.org/mozilla-central/rev/00c0d068ece99717bea7475f7dc07e61f7f35984/toolkit/mozapps/extensions/internal/XPIProvider.jsm#652-659

Do we really need to create this at this point? Presumably we could create it on the first install?

(In reply to :Gijs (he/him) from comment #5)

Do we really need to create this at this point? Presumably we could create it on the first install?

According to Kris we do need to do it here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1460610#c2
https://bugzilla.mozilla.org/show_bug.cgi?id=1460610#c4

Hey aswan,

Can I presume correctly that you're unlikely to work on this anytime soon? If so (or if I don't hear back by the end of the week), I'll unassign you.

Correct, sorry :/

I didn't find a bug for remove osfile.jsm usage from XPIProvider.jsm, but in the meantime I linked as dependencies the other ones related to ongoing work relevant to close this issue.

(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #9)

I didn't find a bug for remove osfile.jsm usage from XPIProvider.jsm, but in the meantime I linked as dependencies the other ones related to ongoing work relevant to close this issue.

Bug 1649590 is for XPIProvider.jsm.

(In reply to Mathew Hodson from comment #10)

(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #9)

I didn't find a bug for remove osfile.jsm usage from XPIProvider.jsm, but in the meantime I linked as dependencies the other ones related to ongoing work relevant to close this issue.

Bug 1649590 is for XPIProvider.jsm.

Thanks Matthew! Yeah, the metabug is bug 986145. I've added both here. I think AM might still be using OS.File through JSONFile, but I haven't checked. That's one of the few remaining open (gnarly!) deps of the metabug...

(In reply to :Gijs (he/him) from comment #11)

I think AM might still be using OS.File through JSONFile, but I haven't checked. That's one of the few remaining open (gnarly!) deps of the metabug...

In fact, Luca, that bug (bug 1649604) looks like the last backout was for AM-related xpcshell tests so if you have time to help there, I'm sure Emma would not say no to that...

(In reply to :Gijs (he/him) from comment #12)

(In reply to :Gijs (he/him) from comment #11)

I think AM might still be using OS.File through JSONFile, but I haven't checked. That's one of the few remaining open (gnarly!) deps of the metabug...

In fact, Luca, that bug (bug 1649604) looks like the last backout was for AM-related xpcshell tests so if you have time to help there, I'm sure Emma would not say no to that...

Hi Gijs,
Thanks for pointing that out. Emma and I discussed about it over slack today, we have some theories and agreed what to look into to follow up with that backout.

I've just filed a set of mentored bugs against bug 1703357 which are working towards achieving the same goal (having found that one first). I'll add it as a dependency and we can hopefully resolve both at the same time.

(In reply to Mark Banner (:standard8) from comment #14)

I've just filed a set of mentored bugs against bug 1703357 which are working towards achieving the same goal (having found that one first). I'll add it as a dependency and we can hopefully resolve both at the same time.

Can we close this now?

I think we can call this one fixed now - add-on manager isn't using OS.File before first paint, so that's objective achieved (there's one other bit of code, but that's bug 1649605).