Closed Bug 827502 Opened 12 years ago Closed 12 years ago

Repeated install of packaged app leaves it in half-deleted state

Categories

(Core Graveyard :: DOM: Apps, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(blocking-basecamp:+, firefox19 wontfix, firefox20 wontfix, firefox21 fixed, b2g18 fixed)

VERIFIED FIXED
mozilla21
blocking-basecamp +
Tracking Status
firefox19 --- wontfix
firefox20 --- wontfix
firefox21 --- fixed
b2g18 --- fixed

People

(Reporter: jduell.mcbugs, Assigned: Margaret)

References

Details

(Keywords: dataloss)

Attachments

(1 file)

This is a followup to bug 826846. Once we get rid of the HomeScreen crash, I'm seeing the following when I follow the steps in bug 826846 comment 0. When I install the app for the 2nd time, it leaves an icon on the desktop, but it's application.zip file is missing (perhaps the install tries to delete the initial install then somehow fails?). If I click the icon, nothing happens. If I try to delete it, it won't delete, and when I reboot the phone, the icon has a little animation around the edges, like it's busy or installing or something, but I suspect it's just wedged somehow.
blocking-basecamp: --- → ?
Component: Gaia → DOM: Apps
Keywords: dataloss
Product: Boot2Gecko → Core
Version: unspecified → Trunk
Noming only because the reinstall is causing dataloss and making it to remove the app. Normally I wouldn't block on reinstall issues, the dataloss and negative effects on the user's phone makes me think this could be worth blocking on.
Blocking, and over to Fabrice.
Assignee: nobody → fabrice
blocking-basecamp: ? → +
I'm having trouble reproducing this using the lasted gaia/b2g18 (with the patch for bug 826846). Jason, are you still seeing this?
(In reply to Margaret Leibovic [:margaret] from comment #3) > I'm having trouble reproducing this using the lasted gaia/b2g18 (with the > patch for bug 826846). > > Jason, are you still seeing this? Actually, I was doing this wrong. I am seeing problems. (Jason^2 helped me figure that out).
It seems like something is going wrong the first time a packaged app is installed. Here's the log from 2 subsequent installs: I/GeckoDump( 580): XXX FIXME : Got a mozContentEvent: webapps-install-granted E/GeckoConsole( 794): [JavaScript Error: "TypeError: request.result.manifest is undefined" {file: "http://mozqa.com/webapi-permissions-tests/apps.js" line: 19}] I/GeckoDump( 580): XXX FIXME : Got a mozContentEvent: webapps-install-granted E/GeckoConsole( 794): [JavaScript Error: "TypeError: request.result.manifest is undefined" {file: "http://mozqa.com/webapi-permissions-tests/apps.js" line: 19}] I/Gecko ( 580): RemoteOpenFileParent: file '/data/local/webapps/{c80cd6b0-3dfa-4274-8aa4-187a6d2b9b79}/application.zip' was not found! I/Gecko ( 683): RemoteOpenFileChild: file was not opened! I/Gecko ( 580): RemoteOpenFileParent: file '/data/local/webapps/{c80cd6b0-3dfa-4274-8aa4-187a6d2b9b79}/application.zip' was not found! I/Gecko ( 683): RemoteOpenFileChild: file was not opened!
Attached patch patch (deleted) — Splinter Review
Fabrice came up with this idea, and it fixes the problem. Instead of trying to install a separate packaged app, we'll now update the already installed app with the same manifestURL. Fabrice, are there tests that this might break?
Assignee: fabrice → margaret.leibovic
Attachment #699116 - Flags: review?(fabrice)
(In reply to Margaret Leibovic [:margaret] from comment #6) > Fabrice, are there tests that this might break? Unfortunately not.
cc'ing Dale and Etienne, since they've been working on packaged app updates.
Attachment #699116 - Flags: review?(fabrice) → review+
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
Keywords: verifyme
QA Contact: jsmith
lgtm on 1/10 build.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Blocks: app-install
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: