The TEF marketplace webapp manifest does not match the default on-device marketplace webapp manifest, which causes updates to fire on device immediately

RESOLVED FIXED

Status

Marketplace
General
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: marcia, Assigned: cvan)

Tracking

({unagi})

ARM
Gonk (Firefox OS)
unagi
Points:
---

Details

(Whiteboard: [triaged:1/15])

Attachments

(1 attachment)

Created attachment 702313 [details]
Screenshot of issue

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.
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

Updated

5 years ago
Blocks: 728081
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.
blocking-b2g: tef? → tef+
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.
Flags: needinfo?(21)
Keywords: qawanted
QA Contact: jsmith
Whiteboard: [triaged:1/15]

Comment 4

5 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.
Assignee: nobody → felash
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.
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.
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.
blocking-b2g: tef+ → tef?
Flags: needinfo?(21)
(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.
Summary: [updates] Getting update prompts for Maps and Marketplace after a fresh flash → [updates] Getting update prompts for Marketplace after a fresh flash
For marketplace I guess we'd need to pre-populate the appcache, but I have no clue on how to do this.
(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.
Assignee: felash → dpreston
Keywords: qawanted
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.
Assignee: dpreston → nobody
blocking-b2g: tef? → ---

Updated

5 years ago
Component: Gaia::System → General
Product: Boot2Gecko → Marketplace
Version: unspecified → 1.0

Updated

5 years ago
Summary: [updates] Getting update prompts for Marketplace after a fresh flash → The TEF marketplace webapp manifest does not match the default on-device marketplace webapp manifest, which causing updates to fire on device immediately

Updated

5 years ago
Summary: The TEF marketplace webapp manifest does not match the default on-device marketplace webapp manifest, which causing updates to fire on device immediately → The TEF marketplace webapp manifest does not match the default on-device marketplace webapp manifest, which causes updates to fire on device immediately
Comment 11 sounds right, it sounds like https://marketplace.firefox.com/telefonica/manifest.webapp needs to remove the appcache line.
(Assignee)

Comment 13

5 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.
Assignee: nobody → cvan
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2013-01-17
(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!
Moving to b2g to clear the tracking flag. Then, I'll move it back.
Component: General → General
Product: Marketplace → Boot2Gecko
Target Milestone: 2013-01-17 → ---
Version: 1.0 → unspecified

Updated

5 years ago
tracking-b2g18: ? → ---

Updated

5 years ago
Component: General → General
Product: Boot2Gecko → Marketplace
Version: unspecified → 1.0
You need to log in before you can comment on or make changes to this bug.