DOMApplicationRegistry._readManifest() does a blocking file read, as far as I can tell on the mainthread. Not good. I strongly recommend using NetUtil.asyncFetch(), which is already used in DOMApplicationRegistry.init()!
In general, could we add some aborts to prevent any new main thread I/O?
How would you distinguish the new main thread i/o from the existing main thread i/o?
I don't know :) That is why I asked if we could add something for the new stuff. Maybe static
analysis could help here?
(In reply to Kyle Huey [:khuey] (email@example.com) from comment #2)
> How would you distinguish the new main thread i/o from the existing main
> thread i/o?
I like the idea, but it's off-topic for this bug. I filed bug 707196 to get this discussion going.
(In reply to Olli Pettay [:smaug] from comment #1)
> In general, could we add some aborts to prevent any new main thread I/O?
We have too much main thread I/O still, sadly. It'd help if reviewers were a bit more strict about this...
This was added by bug 697383. Can we either back that out or fix it before we release this API?
Created attachment 578656 [details] [diff] [review]
This patch adds a _loadJSONAsync() method that is used both in init() and in _readManifest()
Comment on attachment 578656 [details] [diff] [review]
>+ while (!loaded)
Please no event loop spinning either. It's being done in Sync and we've spent the last 8 months trying to get rid of it...
Can't you just make the manifest loading operation take a callback?
Created attachment 578931 [details] [diff] [review]
Here's a fully async version, with callbacks everywhere.
Comment on attachment 578931 [details] [diff] [review]
Boy, the enumerateX APIs complicate this. Also, is getManifestFor part of the API or a helper? I don't see it used in the code.
Mark, the getManifestFor() is a helper for chrome consumers of the API (currently it's used to implement launch() on desktop)