Build: B2G 18 1/22/2013 Device: Unagi Steps: 1. Install a packaged app that will fit on your phone 2. Update the packaged app on the server to a size that will not fit on your phone. Example below: { "name" : "Test WebAPI Permissions", "version" : "1.1", "size" : 10000000000000000000000000000000000000000000000000000000000000000000000000, "release_notes": "First v1.1 release", "icons": { "126": "/webapi-permissions-tests/qalogo.png" }, "developer": { "name": "Mozilla QA", "url": "http://jasondanielsmith.wordpress.com/" }, "package_path": "/webapi-permissions-tests/simple_packaged_update/state2.zip" } 3. Check for updates (manual or automatic) 4. Try to apply the update Expected: The update should fail with an insufficient storage error thrown. Actual: The update fails, but we lose the original old app in the process. This means that you will no longer be able to launch the v1.0 packaged app that was originally installed on the device. If you restart the phone, the app icon switches to a generic, greyed out version. Clicking it allows you to "restart the download." Sounds like what happened here is that we mangled the install failure logic to "restart download" and update logic where we should retain the old app as functional if we fail to download. Additional Notes: Definitely a blocker - this is dataloss if you update to an app where you do not have storage to fit the update, as you will lose the original packaged app installed.

We were actually not losing data, but we reverted the app installation state to "pending" instead of "installed". With this patch we fail correctly, and keep the app launchable. There's one remaining issue with gaia that keep prompting for an update, which I don't understand since the state of the app at this point is : "installState": "installed", "downloadAvailable": false, "downloading": false, "readyToApplyDownload": false, Julien, can you take a look at the gaia side?

Comment on attachment 705148 [details] [diff] [review] patch Review of attachment 705148 [details] [diff] [review]: ----------------------------------------------------------------- r=me

Comment on attachment 705148 [details] [diff] [review] patch Review of attachment 705148 [details] [diff] [review]: ----------------------------------------------------------------- sorry, I can't apply it on a clean b2g18 tree... should I use a mozcentral tree instead ?

This apply on top of 831644 and 832408

Hmm....does this bug fix a different scenario such as the following? 1. Install a packaged app 2. Update it on the server 3. Check for updates 4. Kill the network connection 5. Try to apply the update Result - app update fails and the app can no longer be launched. If you restart the phone, the app enters the exact same state described in this bug - it enters the generic icon when clicked, tries to re-download the update.

Another example scenario: 1. Install a packaged app that's web type 2. Update it on the server to a packaged app that's privileged type non-signed 3. Check for updates 4. Apply the update Result - same result from comment 5 Which makes me think that this bug is fixing the general error case, right?

(In reply to Jason Smith [:jsmith] from comment #5) > Hmm....does this bug fix a different scenario such as the following? > > 1. Install a packaged app > 2. Update it on the server > 3. Check for updates > 4. Kill the network connection > 5. Try to apply the update > > Result - app update fails and the app can no longer be launched. If you > restart the phone, the app enters the exact same state described in this bug > - it enters the generic icon when clicked, tries to re-download the update. With a build from https://tbpl.mozilla.org/?tree=Try&rev=1f047c64e5ce, we fail properly: the app update fails after the network timeout. We can still launch the app, including after a restart.

(In reply to Fabrice Desré [:fabrice] from comment #1) > Created attachment 705148 [details] [diff] [review] > patch > > We were actually not losing data, but we reverted the app installation state > to "pending" instead of "installed". With this patch we fail correctly, and > keep the app launchable. > > There's one remaining issue with gaia that keep prompting for an update, > which I don't understand since the state of the app at this point is : > > "installState": "installed", > "downloadAvailable": false, > "downloading": false, > "readyToApplyDownload": false, > > Julien, can you take a look at the gaia side? In my testing, I have : "downloadAvailable": true, Which is perfectly normal for me: the update was not downloaded, it's still lying on the server :) We do catch the error (there is a SystemBanner message that there was an error while downloading the update, and there is the "INSUFFICIENT_STORAGE" message in the log). So this seems fine to me.

Verified on 1/25 build.

Landed on mozilla-b2g18/gaia master prior to the 1/25 branching to mozilla-b2g18_v1_0_0/v1.0.0, updating status-b2g-v1.0.0 to fixed.