Closed
Bug 828935
Opened 12 years ago
Closed 12 years ago
When marketplace gets an update on device, and I apply the update, I get reprompted for the update again, again, again, ...
Categories
(Core Graveyard :: DOM: Apps, defect)
Tracking
(blocking-basecamp:+)
RESOLVED
WORKSFORME
blocking-basecamp | + |
People
(Reporter: jsmith, Assigned: julienw)
References
Details
(Keywords: regression)
Build: B2G 18 1/10/2013
Device: Unagi
Steps:
1. With the marketplace having X manifest on your device, ask the marketplace team nicely to someone cause the update to happen
2. Check for updates (manual or automatic)
3. Apply the update available from the update notification
Expected:
The update should applied - no repeated prompts should be seen.
Actual:
After applying an update, the update available prompt appears again. If I then try to apply the update, the update available prompt appears following the update again as well. What's going wrong here? Are we even applying an update here? Firing an update available unexpectedly?
Reporter | ||
Updated•12 years ago
|
blocking-basecamp: --- → ?
Reporter | ||
Comment 1•12 years ago
|
||
Julien mentioned that he managed to reproduce this as well yesterday. I just got this to reproduce on today's build.
Comment 2•12 years ago
|
||
Damn, I'm pretty sure we fixed that at some point before.
Reporter | ||
Updated•12 years ago
|
Keywords: regression,
regressionwindow-wanted
Reporter | ||
Comment 3•12 years ago
|
||
Here's the state of marketplace I have on my device right now with an update available:
"marketplace": {
"origin": "https://marketplace.firefox.com/telefonica/",
"installOrigin": "https://marketplace.firefox.com/telefonica/",
"receipt": null,
"installTime": 132333986000,
"manifestURL": "https://marketplace.firefox.com/telefonica/manifest.webapp",
"localId": 1021,
"etag": "\"2a5aa6f98e39355390293b78b4c27204\"",
"packageEtag": null,
"basePath": "/data/local/webapps",
"id": "marketplace",
"removable": false,
"name": "Firefox Marketplace",
"csp": "",
"lastCheckedUpdate": 1357819234185,
"installState": "installed",
"downloading": false,
"downloadSize": 0,
"readyToApplyDownload": false,
"downloadAvailable": false,
"updateTime": 1357818874742,
"retryingDownload": false
},
Reporter | ||
Comment 5•12 years ago
|
||
Talked with Fabrice on this one.
What's weird about this is that the values are all false above, implying that we shouldn't be getting an update fired to Gaia. But Gaia appears to be getting the update repeatedly.
Etienne - Any ideas?
Flags: needinfo?(etienne)
Comment 6•12 years ago
|
||
If downloadAvailable is false in webapps.json then it can be:
- we didn't clean on the gaia side after the update (are you still seeing the notification after a reboot?)
- we're actually somehow getting a ondownloadavailable callback
Flags: needinfo?(etienne)
Updated•12 years ago
|
Assignee: nobody → etienne
Assignee | ||
Updated•12 years ago
|
Assignee: etienne → felash
Assignee | ||
Comment 7•12 years ago
|
||
I think I found this bug and fixed this in Bug 826946.
The problem was that at reboot for some reason, the install manager would register the events on the app even if it was installed whereas it should do that only for pending apps.
Therefore, the downloadsuccess event was never received by the update manager, and therefore the update was never applied. Instead, we get the "app installed" banner which we shouldn't have at update.
Depends on: 826946
Assignee | ||
Comment 8•12 years ago
|
||
Ok, there is something else happening, I'm trying to investigate more.
Updated•12 years ago
|
blocking-basecamp: + → -
Updated•12 years ago
|
blocking-basecamp: - → +
Comment 10•12 years ago
|
||
Julien's going to check whether or not this was fixed as part of another bug. If Fabrice and Julien are too busy, Andrea can perhaps help.
Assignee | ||
Comment 11•12 years ago
|
||
This seems fixed for me.
Closing it for now, please reopen if I'm wrong.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Updated•9 years ago
|
Keywords: regressionwindow-wanted
Updated•7 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•