Updating a packaged app to a new version that is too large to fit in the phone fails, but the original packaged app is lost (no longer launches)

VERIFIED FIXED in Firefox 21

Status

defect
VERIFIED FIXED
7 years ago
2 years ago

People

(Reporter: jsmith, Assigned: fabrice)

Tracking

({dataloss})

Trunk
mozilla21
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:tef+, firefox19 wontfix, firefox20 wontfix, firefox21 fixed, b2g18 fixed, b2g18-v1.0.0 fixed)

Details

Attachments

(1 attachment)

Reporter

Description

7 years ago
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.
Reporter

Updated

7 years ago
blocking-b2g: --- → tef?
Keywords: dataloss
Assignee

Comment 1

7 years ago
Posted patch patchSplinter Review
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?
Assignee: nobody → fabrice
Attachment #705148 - Flags: review?(ferjmoreno)
Flags: needinfo?(felash)
Comment on attachment 705148 [details] [diff] [review]
patch

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

r=me
Attachment #705148 - Flags: review?(ferjmoreno) → review+
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 ?
Flags: needinfo?(felash)
Assignee

Comment 4

7 years ago
This apply on top of 831644 and 832408
Assignee

Updated

7 years ago
blocking-b2g: tef? → tef+
Reporter

Comment 5

7 years ago
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.
Reporter

Comment 6

7 years ago
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?
Assignee

Comment 7

7 years ago
(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.
Reporter

Updated

7 years ago
Duplicate of this bug: 834166
(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.
Reporter

Updated

7 years ago
Duplicate of this bug: 834166
Assignee

Comment 12

7 years ago
https://hg.mozilla.org/releases/mozilla-b2g18/rev/8ab7e45fc123
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Reporter

Updated

7 years ago
Keywords: verifyme
QA Contact: jsmith
Reporter

Comment 13

7 years ago
Verified on 1/25 build.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Target Milestone: --- → mozilla21
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.

Updated

2 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.