Closed Bug 803718 Opened 12 years ago Closed 12 years ago

B2G Appcache storing entries in wrong namespace.

Categories

(Firefox OS Graveyard :: General, defect)

defect
Not set
normal

Tracking

(blocking-basecamp:+)

RESOLVED DUPLICATE of bug 796278
blocking-basecamp +

People

(Reporter: jduell.mcbugs, Unassigned)

References

Details

DOMApplicationRegistry.startOfflineCacheDownload is not providing an nsILoadContext to nsOfflineCacheUpdateService::ScheduleUpdate, so we wind up storing appcache entries in the default (appId=0, inBrowser=false) namespace.  Presumably the result is that when an app actually loads, we don't find the entries in the appcache and have to fetch from network (I haven't verified this: we also need testcoverage here, which I'm planning to base off mouinir's app test for cookies in test_app_uninstall_cookies.html unless someone points me at something better).

The Loadcontext currently gets grabbed off an optional Window argument.  That may need to change to pass the nsILoadContext directly, since we may not have a window to pass in in e10s (but we should have the channel somewhere and thus the LC).
blocking-basecamp: --- → ?
Jason, I think this is a dupe of bug 796278, that I planned to fix using the new API from bug 794663. Am I misunderstanding what's provided by the patch in bug 794663 ?
Yup, it's a dupe
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Dupe is a blocker so marking as a blocker.
blocking-basecamp: ? → +
You need to log in before you can comment on or make changes to this bug.