Marcia Knous [:marcia] Reporter
	Description • 12 years ago

unagi, running that latest nightly build 20130114 

Gaia: 45a3196a5517
Gecko: f2460bf17811

I mentioned this to Jason the other day and he said he thought the bug was fixed but this is still happening for me continuously.

STR:
1. Flash the latest build and go through first run into Porguguese
2. Immediately receive the attached screenshot

If you try to download apply the updates, you get a spinner that never goes away with 0.00 bytes showing being downloaded.

Other times during testing when I pressed the download button, after one second it stops and both prompts go away.

I don't see much happening in logcat at all while this is happening.

	Mike Conley (:mconley) (:⚙️)
	Comment 1 • 12 years ago

I'm seeing the same update prompts for Maps and Marketplace, although I didn't do a fresh flash - I went through the normal update channel.

Build ID: 20130110070201
Git hash: 9d4983b18d

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

Seen this as well, but I don't know if we can effectively mitigate this other than doing a temporary update. It's possible we could ship and require an update at the start.

	Julien Wajsberg [:julienw]
	Comment 3 • 12 years ago

Current Maps has an incorrect update.manifest (gets a 404) so I doubt you can have an update.

Anyway, for both, we should store the current ETag in their metadata.json and then we wouldn't get an update.

But this will need to be changed each time the app changes. I believe this should be automatically retrieved at build time, but then a build would need a network connection.

Asking for more info from vivien on this.

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

Let's not fix anything besides the update.manifests in this bug, if that alone prevents the unnecessary update prompts for Marketplace. bug 830913 is for Maps, this bug will be for Marketplace.

	Julien Wajsberg [:julienw]
	Comment 5 • 12 years ago

The manifest is OK for the Marketplace. We need to configure what the current ETag are to not get the update notification. Which means, as I said, that each time the server ETag change we'd have to change it here too.

Will discuss this with Vivien today.

	Julien Wajsberg [:julienw]
	Comment 6 • 12 years ago

I can still update to the current ETag for the Marketplace but it will most probably change again before we ship.

I'm not against having an update as soon as we first-boot. Android does it.

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

Even if we set it to the latest Etag it will probably change before we ship - or can we ensure that there won't be any update to the markeplace/maps before the release?

I feel like fixing it right now will result in the same issue in the coming months. Renominating.

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

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #7)
> Even if we set it to the latest Etag it will probably change before we ship
> - or can we ensure that there won't be any update to the markeplace/maps
> before the release?
> 
> I feel like fixing it right now will result in the same issue in the coming
> months. Renominating.

Umm...etags have absolutely nothing to do with this. Hosted apps don't deal with the etag problem.

This bug should be reworked to the marketplace problem - which is the problem that the manifest probably needs to be finalized. Manifests don't change that often, so the problem you are talking about I don't expect to happen that often.

etags also don't apply to why the maps app is having to repeatedly fire updates - it's because of a bad manifestURL. There's a separate bug tracking this.

	Julien Wajsberg [:julienw]
	Comment 9 • 12 years ago

For marketplace I guess we'd need to pre-populate the appcache, but I have no clue on how to do this.

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

(In reply to Julien Wajsberg [:julienw] from comment #9)
> For marketplace I guess we'd need to pre-populate the appcache, but I have
> no clue on how to do this.

Marketplace no longer preloads an appcache. It's just an app manifest on device.

I'll redirect to Donovan as I think he knows what to do here.

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

Hold up a sec. I know what the problem is.

On gaia, our default webapp manifest we have marketplace does *not* have an appcache preloaded:

https://github.com/mozilla-b2g/gaia/blob/master/external-apps/marketplace/manifest.webapp

However, the marketplace webapp manifest *does* preload the appcache:

https://marketplace.firefox.com/telefonica/manifest.webapp

This is causing the update to happen right away. Given the fact we've taken preloading the appcache for marketplace out of scope on device, this is now a marketplace bug. They need to fix their telefonica webapp manifest to match the default on device.

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

Comment 11 sounds right, it sounds like https://marketplace.firefox.com/telefonica/manifest.webapp needs to remove the appcache line.

	Christopher Van Wiemeersch [:cvan] Assignee
	Comment 13 • 12 years ago

(In reply to Donovan Preston from comment #12)
> Comment 11 sounds right, it sounds like
> https://marketplace.firefox.com/telefonica/manifest.webapp needs to remove
> the appcache line.

This was done a few days ago - https://github.com/mozilla/zamboni/commit/1504832 - and will be pushed to production tomorrow (Thurs, 1/17) at 2:00 PST.

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

(In reply to Chris Van Wiemeersch [:cvan] from comment #13)
> (In reply to Donovan Preston from comment #12)
> > Comment 11 sounds right, it sounds like
> > https://marketplace.firefox.com/telefonica/manifest.webapp needs to remove
> > the appcache line.
> 
> This was done a few days ago -
> https://github.com/mozilla/zamboni/commit/1504832 - and will be pushed to
> production tomorrow (Thurs, 1/17) at 2:00 PST.

Sweetness!

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

Moving to b2g to clear the tracking flag. Then, I'll move it back.