Closed Bug 962229 Opened 7 years ago Closed 7 years ago

JS Error on startup - DOMApplicationRegistry: DOMApplicationRegistry: Could not read from json file /data/data/org.mozilla.fennec/files/mozilla/webapps/webapps.json


(Firefox for Android :: Web Apps (PWAs), defect)

29 Branch
Not set



Firefox 29
Tracking Status
firefox29 --- verified
fennec - ---


(Reporter: aaronmt, Assigned: myk)



(Keywords: regression, reproducible)


(1 file)

E/GeckoConsole( 9158): [JavaScript Error: "DOMApplicationRegistry: Could not read from json file /data/data/org.mozilla.fennec/files/mozilla/webapps/webapps.json" {file: "resource://gre/modules/Webapps.jsm" line: 816}]

E/GeckoConsole( 9158): [JavaScript Error: "DOMApplicationRegistry: Could not parse JSON: /data/data/org.mozilla.fennec/files/mozilla/webapps/webapps.json [Exception... "Component returned failure code: 0x80470002 (NS_BASE_STREAM_CLOSED) [nsIInputStream.available]"  nsresult: "0x80470002 (NS_BASE_STREAM_CLOSED)"  location: "JS frame :: resource://gre/modules/Webapps.jsm :: this.DOMApplicationRegistry._loadJSONAsync/< :: line 828"  data: no]

E/GeckoConsole( 9158): undefined" {file: "resource://gre/modules/Webapps.jsm" line: 834}]

I haven't checked to see what benign effects this causes, but I see this on startup with a fresh profile on Nightly (01/21).

Nightly (01/21)
Samsung Galaxy SIV (Android 4.4.2)
Synthetic APKs are still disabled on Nightly builds, so this shouldn't be the result of synthetic APKs (which in any case landed back on January 9).  But Marco has made three subsequent changes to Webapps.jsm; perhaps one of those caused this problem?

cc:ing folks.
Confirmed by reverting revision <> that this is a regression from bug 959420.
Blocks: 959420
Note that I see this on firstrun but not on subsequent run.
These are actually spurious error messages.  loadCurrentRegistry used to check that the registry file exists before trying to load it, but now it just tries to load it, which results in NS_ERROR_FILE_NOT_FOUND on Fennec firstrun.

Nevertheless, _loadJSONAsync should return early after it determines that the channel could not be fetched, like it used to.  Instead, it now tries to read from the stream anyway, resulting in NS_BASE_STREAM_CLOSED.  So the first fix in this patch is to return early in that case.

But that still doesn't suppress the first spurious message.  To fix that, we could make loadCurrentRegistry call OS.File.exists() to ensure the file exists before loading it, but I hear OS.File is slow to load and shouldn't be on the startup path.  Plus OS.File.exists() has this performance note:

    Performance note: For the sake of performance, you should avoid this
    function whenever possible. For instance, rather than calling exists()
    to determine if a directory should be created with makeDir, you should
    rather create the directory with makeDir and catch the error if the
    directory exists. This will ensure that you only need to perform one I/O
    operation rather than two.

So the second fix in this patch is to check the result of NetUtil.asyncFetch and suppress the error message if it's NS_ERROR_FILE_NOT_FOUND.
Assignee: nobody → myk
Attachment #8363470 - Flags: review?(fabrice)
Attachment #8363470 - Flags: review?(fabrice) → review+
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
tracking-fennec: ? → -
You need to log in before you can comment on or make changes to this bug.