GH to BZ Reporter
	Description • 12 years ago

[GitHub issue by potch on 2012-08-15T23:56:35Z, https://github.com/mozilla-b2g/gaia/issues/3492]
If I create an external app (such as Marketplace) and provide an `appcache_path` in the manifest, the cache should be pre-populated as if the app was installed via the app runtime.

	GH to BZ Reporter
	Comment 1 • 12 years ago

[GitHub comment by jds2501 on 2012-08-27T12:41:36Z]
Note - only applies to apps preloaded on the phone.

	GH to BZ Reporter
	Comment 2 • 12 years ago

[GitHub comment by fabricedesre on 2012-08-27T14:09:08Z]
This needs to be done at build time, which means that the resources to preload must be available locally (we don't want to fetch from the network at build time). @potch knows what to do!

	GH to BZ Reporter
	Comment 3 • 12 years ago

[GitHub comment by autonome on 2012-09-05T06:09:54Z]
so who's fixing this.

	GH to BZ Reporter
	Comment 4 • 12 years ago

[GitHub comment by autonome on 2012-09-05T06:10:04Z]
more importantly, does this block the release?

	GH to BZ Reporter
	Comment 5 • 12 years ago

[GitHub comment by jds2501 on 2012-09-05T14:53:46Z]
@autonome Marketplace has claimed it's a P1 on their basecamp tracking bug for the associated bug this blocks - https://bugzilla.mozilla.org/show_bug.cgi?id=768946. So this definitely blocks.

	GH to BZ Reporter
	Comment 6 • 12 years ago

[GitHub comment by vingtetun on 2012-09-05T15:17:51Z]
We need the source code the will be pre-loaded instead of loading it from the internet. @potch Can you provide it? If so I can take care of that and/or find resources to help here.

	GH to BZ Reporter
	Comment 7 • 12 years ago

[GitHub comment by autonome on 2012-09-05T15:18:51Z]
If I understand this right, this is not going to be sufficient. This means that the build system needs to hope and pray that the Marketplace is able to be pulled from the internet every time we build.

Can we not do periodic drops into the Gaia repo on Marketplace release day?

	GH to BZ Reporter
	Comment 8 • 12 years ago

[GitHub comment by cgjones on 2012-09-05T16:45:11Z]
We need to have a chat with akeybl and @cleemoz about this delivery mechanism.

	GH to BZ Reporter
	Comment 9 • 12 years ago

[GitHub comment by cleemoz on 2012-09-06T01:51:14Z]
This sounds like a blocker to me and @andreasgal mentioned a possible solution here.  Cjones, maybe you can sync with Andreas on this?

	GH to BZ Reporter
	Comment 10 • 12 years ago

[GitHub comment by autonome on 2012-09-07T16:24:03Z]
Blocking - we need to figure out a solution one way or the other.

	GH to BZ Reporter
	Comment 11 • 12 years ago

[GitHub comment by potch on 2012-09-14T21:00:42Z]
Is this assigned or being worked on? For better or worse, we need this for our October deliverable. Lack of pre-cache is a huge performance issue for us.

	GH to BZ Reporter
	Comment 12 • 12 years ago

[GitHub comment by potch on 2012-09-19T22:29:17Z]
Opened https://github.com/mozilla-b2g/gaia/pull/4930 to provide some test media for the marketplace-dev external app.

	GH to BZ Reporter
	Comment 13 • 12 years ago

[GitHub comment by potch on 2012-09-24T17:50:39Z]
Updated the PR to include the cache manifest- remember not to put the manifest file itself in the offline cache, or you're gonna have a bad time :)

	Alex Keybl [:akeybl]
	Comment 14 • 12 years ago

Sending over to Fabrice - please reassign as you see fit.

	Donovan Preston [:fzzzy]
	Comment 16 • 12 years ago

This is pretty important. Currently performance of large apps that are installed over the web is very bad the first time the app is run because the assets were not downloaded and cached ahead of time when the app was installed.

If I install the same large app by putting it in the gaia/apps directory and running make install-gaia, the difference is extremely noticeable.

	Chris Lee [:clee]
	Comment 17 • 12 years ago

What's the status of this bug?

Per comment 16, this is very important to the experience for all pre-loaded apps and sets a poor first impression.

	Alexandre Poirot [:ochameau] Assignee
	Comment 18 • 12 years ago

I was thinking that it was some almost duplicate of bug 791039.
But given comment 16, I have a better picture of the original request.
Note that bug 791039 is going to allow to ship a cached version of the marketplace-dev application as a third party application.
But it won't change anything for apps installed by the user.

From what I have seen there is already a bunch of code to download files into offline cache. I'll take a look at that tomorrow.

	[:fabrice] Fabrice Desré
	Comment 19 • 12 years ago

Not sure why you changed the assignee, but we know what we need here, which is the new API from bug 794663.

	Jason Duell
	Comment 20 • 12 years ago

> the new API from bug 794663.

which should land in the next few days.  If someone wants to get started on this bug in the meantime, you can start coding for the new scheduleAppUpdate() (instead of scheduleUpdate) API.

	Alexandre Poirot [:ochameau] Assignee
	Comment 21 • 12 years ago

(In reply to Fabrice Desré [:fabrice] from comment #19)
> Not sure why you changed the assignee, but we know what we need here, which
> is the new API from bug 794663.

I'm here to contribute and offload some of b2g team bugs. Vivien thought this bug would be a good candidate for me, as I already started working on offline-cache. Having said that if you want to do it, feel free to take back the assignment.

	Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)
	Comment 22 • 12 years ago

Since it does not affect preloaded apps anymore this is not a blocker but a fix would be good for downloaded apps.

	Jason Smith [:jsmith]
	Comment 23 • 12 years ago

(In reply to Vivien Nicolas (:vingtetun) from comment #22)
> Since it does not affect preloaded apps anymore this is not a blocker but a
> fix would be good for downloaded apps.

What bug fixed this for preloaded apps then? 

Also - to my understanding this bug has nothing to do with downloaded apps - I thought that already works?

	[:fabrice] Fabrice Desré
	Comment 24 • 12 years ago

(In reply to Jason Smith [:jsmith] from comment #23)
> (In reply to Vivien Nicolas (:vingtetun) from comment #22)
> > Since it does not affect preloaded apps anymore this is not a blocker but a
> > fix would be good for downloaded apps.
> 
> What bug fixed this for preloaded apps then? 

bug 791039

> Also - to my understanding this bug has nothing to do with downloaded apps -
> I thought that already works?

No, it's broken because of the data jars. We definitely want that to work.

	Donovan Preston [:fzzzy]
	Comment 25 • 12 years ago

\o/

	Donovan Preston [:fzzzy]
	Comment 26 • 12 years ago

Oh, I guess I prematurely celebrated... I thought 791039 getting fixed fixed this. Horray on this getting a blocking+, look forward to this being fixed.

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 27 • 12 years ago

What does this bug cover? Comment 1 says that this only covers "apps preloaded on the phone", whereas the bug summary and comment 16 talks about "downloaded apps" and "apps that are installed over the web", neither of which applies to preloaded apps.

	[:fabrice] Fabrice Desré
	Comment 28 • 12 years ago

Jonas, how can an appcache issue not be confusing ;) ?

To me this bug is about hosted apps that specify an appcache_path in their manifest. For now we download the cache but not with the appId so we don't use it afterwards. Now that bug 794663 we can use the new API to fix that.

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 29 • 12 years ago

If that's the case, then this is simply a dupe of bug 796045.

But I get the impression that some people were thinking that this bug covered preinstalled apps.

If anyone does, can you please describe exactly what doesn't work as expected? With steps to reproduce and "expected behavior"/"actual behavior".

	[:fabrice] Fabrice Desré
	Comment 30 • 12 years ago

I agree this is a dupe of bug 796045. Preinstalled apps were done in bug 791039.

	Alexandre Poirot [:ochameau] Assignee
	Comment 33 • 12 years ago

Comment on attachment 676619 [details] [diff] [review]
Bug 796278: Prepopulate apps cache for specific mozbrowser frames

Looks like a simple one.
Tested manually on device against: http://test.techno-barje.fr/webapp/

(keep in mind while testing this, that any error in the appcache manifest, like a missing file, will end up with a broken app. See bug 796820)

	[:fabrice] Fabrice Desré
	Comment 34 • 12 years ago

Comment on attachment 676619 [details] [diff] [review]
Bug 796278: Prepopulate apps cache for specific mozbrowser frames

Review of attachment 676619 [details] [diff] [review]:
-----------------------------------------------------------------

r=me, but move this patch to bug 796045 since this one is closed.