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

Status: VERIFIED FIXED

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

Description

[Aaron Train [:aaronmt]]

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)

Comment 1

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 2

[Myk Melez [:myk] [@mykmelez]]

Confirmed by reverting revision <http://hg.mozilla.org/mozilla-central/rev/75a010e3f038> that this is a regression from bug 959420.

Comment 3

[Myk Melez [:myk] [@mykmelez]]

Note that I see this on firstrun but not on subsequent run.

Comment 4

[Myk Melez [:myk] [@mykmelez]]

Attachment: 0001-bug-962229-suppress-spurious-error-messages-about-we.patch

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.

Comment 5

[Myk Melez [:myk] [@mykmelez]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/eb0b4a0e5ff9

Comment 6

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/eb0b4a0e5ff9