There's a race condition that prevents using OS.File in the startup path in Webapps.jsm. I think the problem is that we should wait for the registry to be loaded before using it. In the webapp runtime we're waiting: http://mxr.mozilla.org/mozilla-central/source/webapprt/Startup.jsm#104 So I think the problem is restricted to b2g. (You can see the problem in this try run: https://tbpl.mozilla.org/?tree=Try&rev=7e86c439da11. I've just replaced a couple of nsIFile::exists with OS.File.exists) Registry loading is asynchronous anyway, so this problem could also arise now, without OS.File (I guess with OS.File it's more noticeable because OS.File may be slower).

Performance note: we are just realizing that OS.File is *very* slow to load (actually, ChromeWorkers are all very slow to load). Be careful if you use it during critical startup path.

(In reply to David Rajchenbach Teller [:Yoric] (please use "needinfo?") from comment #1) > Performance note: we are just realizing that OS.File is *very* slow to load > (actually, ChromeWorkers are all very slow to load). Be careful if you use > it during critical startup path. Is there an alternative? Are there any plans to improve this? (bug #?) The race condition is worth fixing anyway I guess. Right now it shows up only with OS.File, but it could show up when a lot of applications are installed (because at startup we read all their manifests).

Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.