Closed Bug 814114 Opened 12 years ago Closed 11 years ago

App update fails with {JavaScript Error: "DOMApplicationRegistry: Could not read from ...update.webapp: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND)}, w/ "Downloading updates..." notification forever and ever

Categories

(Core Graveyard :: DOM: Apps, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-basecamp:+, b2g18 fixed)

VERIFIED FIXED
B2G C3 (12dec-1jan)
blocking-basecamp +
Tracking Status
b2g18 --- fixed

People

(Reporter: dholbert, Assigned: fabrice)

References

()

Details

(Keywords: b2g-testdriver, unagi)

This morning, when I powered on my phone, I had a notification for an update. I tapped the notification, and I got a full-screen prompt for an update to the "Slithering" app (which I installed yesterday).

I accepted the update, but it didn't install -- instead, I got this in my adb logcat (immediately when I accepted the update):
{
E/GeckoConsole( 1671): [JavaScript Error: "DOMApplicationRegistry: Could not read from /data/local/webapps/{c55e304e-453c-4501-beb6-825e4a6cc873}/update.webapp : [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIChannel.asyncOpen]"  nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame :: resource://gre/modules/NetUtil.jsm :: NetUtil_asyncOpen :: line 165"  data: no]
E/GeckoConsole( 1671): undefined" {file: "resource://gre/modules/Webapps.jsm" line: 516}]
}

I also got a never-going-away "Downloading updates..." notification in my notification area (like the one in bug 812584, but from an app update instead of a system update in this case).  I can tap it to cancel the download, and then it's replaced with the original update notification, which I can accept to repeat the process.
Component: Gaia → DOM: Apps
Product: Boot2Gecko → Core
Fabrice - Any ideas on what's going on here?
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
(CC'ing slithering devs MattN & jaws, in case they have any insights or have hit this themselves)
We both have this too and I started filing this bug but got distracted by another.  I don't have any insights into this other than the fact that we do use AppCache and appcache_path in the app manifest so the game is available offline.  We aren't a packaged app though.
We have however updated the app cache recently (within the past week or two) which might have gotten it into this state.
(In reply to Jared Wein [:jaws] from comment #4)
> We have however updated the app cache recently (within the past week or two)
> which might have gotten it into this state.

Actually, the last change to it was October 28th.
blocking-basecamp: ? → +
Fabrice says there's a fix for this in a different bug. He'll follow up with details later (had to run).
Assignee: nobody → fabrice
Setting priority based on triage discussions.  Feel free to decrease priority if you disagree.
Priority: -- → P1
I tested with the latest nightly, and that seems to be fixed (we landed several fixes to the update and download error reporting in other bugs). Can QA verify?
Keywords: qawanted
Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.
Target Milestone: --- → B2G C3 (12dec-1jan)
QA Contact: tchung → jsmith
No QA yet, but speculatively closing
Status: NEW → RESOLVED
Closed: 11 years ago
Keywords: verifyme
Resolution: --- → FIXED
(In reply to JP Rosevear [:jpr] from comment #10)
> No QA yet, but speculatively closing

Yeah, makes sense. I'll look in a little bit, but I *think* this is fixed for the same reasons Fabrice said in comment 8.
Keywords: qawanted
I haven't seen this bug on the latest builds nor anything that looks like the error seen in the logs. Marking as verified.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.