When I try to install a hosted app preloading appcache that has an invalid appcache path (e.g. 404, bad syntax), we currently report an error code in the console, but we don't provide information on what failed in the appcache. Is the path a 404? Is the appcache syntax invalid? We should both indicate the error code and the reason why the appcache path failed in the logs to improve the developer experience.

IIRC this is difficult right now because the appcache subsystem doesn't report the error to us.

I'm a bit confused as what we want to fix here. Displaying detailed appcache error messages in gaia looks totally useless. Improving what is sent to logcat (by the appcache code itself) is ok.

(In reply to Fabrice Desré [:fabrice] from comment #2) > I'm a bit confused as what we want to fix here. Displaying detailed appcache > error messages in gaia looks totally useless. Improving what is sent to > logcat (by the appcache code itself) is ok. Right, I met logcat, not the Gaia UI. We should definitely not stick this in the UI.

Honza - Do you have any insight here on how we can provide better console error reporting when appcache error is fired?

I really think the log messages are already quite good. I always found the root appcache error when looking at logcat (for example when I was debugging Nicolas app in Bug 835042 which was because of a bad appcache URL). If you think some messages are bad, please say which ones exactly.

(In reply to Julien Wajsberg [:julienw] from comment #5) > I really think the log messages are already quite good. I always found the > root appcache error when looking at logcat (for example when I was debugging > Nicolas app in Bug 835042 which was because of a bad appcache URL). From this comment it sound like you HAD to use logcat to figure the problem out and that the error console logs were not sufficient. Is that so? If yes, then we may need to add more logging. Please let me know.

I debugged on an actual device (because at the time the Firefox OS Simulator was in a bad shape for installing apps) so when I say "logcat" I think it was really the error console for the appcache errors.

The simulator is currently completely borked when it comes to installation with a busted appcache. See here: https://github.com/mozilla/r2d2b2g/issues/306

so unless we have the actual failing error messages, I suggest closing this.

and by "failing", I mean "not clear enough" or "missing".

Let's get more info from Matt on this since he's the reportee here.

As I read the description, it's just about to add a bit more calls to LogToConsole in OfflineCacheUpdate with more verbose info. I can do that.

(In reply to Honza Bambas (:mayhemer) from comment #12) > As I read the description, it's just about to add a bit more calls to > LogToConsole in OfflineCacheUpdate with more verbose info. I can do that. I can get behind that. I'd prefer too much logging than too little logging. Anything so that your average Joe Developer can tell what the problem is without having to spin up Wireshark or gdb through b2g.

Assigning to you then, OK ?

(In reply to Honza Bambas (:mayhemer) from comment #14) > Assigning to you then, OK ? Umm...Matt is a marketplace developer, not a gecko developer. He isn't the right assignee for something like this.

Sounds like the way we would fix this would be in the core networking appcache code, right?

To me the most important missing thing is when the appcache manifest is not downloaded and taken from the HTTP Cache instead. I think there is a bug somewhere about that. Bug 835079 (2nd point) is about adding a log when a _ressource_ is taken from the HTTP Cache. This could make a lot of logs but still could be useful. Maybe this can be added now and removed when our dev tools show this.

I can add all these logs to appcache update code.

appcache is dead