Closed Bug 867045 Opened 13 years ago Closed 13 years ago

[Buri][Home screen]User can delete apps in Idle screen,after download version and reboot handset is not the same

Categories

(Firefox OS Graveyard :: Gaia::Homescreen, defect, P2)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:tef+, b2g18 verified, b2g18-v1.0.1 verified)

VERIFIED FIXED
blocking-b2g tef+
Tracking Status
b2g18 --- verified
b2g18-v1.0.1 --- verified

People

(Reporter: sync-1, Assigned: crdlc)

References

Details

Attachments

(4 files)

+++ This bug was initially created as a clone of Bug #447692 +++ AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.085 Firefox os v1.0.1 Mozilla build ID:20130422230201 Created an attachment (id=400526) Before reboot DEFECT DESCRIPTION: User can delete apps in Idle screen,after download version and reboot handset is not the same REPRODUCING PROCEDURES: 1.Download the new version,eg:SW126 2.Power on,long press any app in Idle screen,user only can delete "Youtobe" app--->KO 3.Reboot handset,long press any app in Idle screen,user can select 13 apps to delete(like attachment) EXPECTED BEHAVIOUR: User can delete apps in Idle screen,after download version and reboot handset should be same ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: REPRODUCING RATE: 5/5 For FT PR, Please list reference mobile's behavior: ++++++++++ end of initial bug #447692 description ++++++++++ CONTACT INFO (Name,Phone number): DEFECT DESCRIPTION: REPRODUCING PROCEDURES: EXPECTED BEHAVIOUR: ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: REPRODUCING RATE: For FT PR, Please list reference mobile's behavior:
Clone from brother
Attached image Before reboot
Clone from brother
Clone from brother
Attached image After reboot
Clone from brother
In gaia/apps/homescreen/js/grid.js var descriptor = { bookmarkURL: app.bookmarkURL, manifestURL: app.manifestURL, entry_point: entryPoint, updateTime: app.updateTime, removable: app.removable, name: iconsAndNameHolder.name, icon: bestMatchingIcon(app, iconsAndNameHolder), useAsyncPanZoom: app.useAsyncPanZoom } removable got from app info. In gaia/apps/homescreen/js/page.js if (descriptor.removable) { // Menu button to delete the app var options = document.createElement('span'); options.className = 'options'; options.dataset.isIcon = true; container.appendChild(options); } If removable is true, the app will be added an options. But first time boot up, the removable infomation from app is not correct. It's just "undefined"
Assignee: nobody → crdlc
Status: NEW → ASSIGNED
Basically the homescreen would add the 'X' icon when <app.removable> is equal to true. This path makes more robust the condition, doesn't fix anything. From my point of view, the problem is in backend instead of Gaia. The <app.removable> info is not correct when the API returns that info sometimes. Maybe, you could view if the homescreen shows removable apps wrong while Settings app is showing this info correctly. IMHO if the info is wrong in home and settings apps the error is on the backend part.
Attachment #752069 - Flags: review?(jmcf)
Attachment #752069 - Flags: review?(jmcf) → review+
Do we need this for tef? leo? Wondering if this blocks either of those releases.
Stealing this, Cristian. From the description I think the problem might be on the platform. I don't think this qualifies as tef+ at this time, requesting leo+ so it can be triaged.
Assignee: crdlc → amac
blocking-b2g: --- → leo?
blocking-b2g: leo? → tef+
This seems to happen when you apply customisation, which is the case for all commercial devices: tef+. Antonio, what is the ETA for this?
Finally I guess that the problem is in Homescreen, sorry
Assignee: amac → crdlc
The first time when the homescreen is launched, it loads apps from the info pre-generated in build time instead of waiting for the info from the API. When the grid is painted, we receive the info from the API, then we updated sadly the icon and label but nothing related to removable flagz. The patch has not risk. Now the 'x' icon is rendered with the info from the API as well or when an app is already installed
Attachment #753725 - Flags: review?(jmcf)
Attachment #753725 - Flags: review?(jmcf) → review+
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
This is blocking the beginning of the certification. Cristian can you please uplift on your own?
I need a better understanding of this bug. Is this basically that on first run, certain apps can't be uninstalled? Post first run after a reboot, they can be?
(In reply to Jason Smith [:jsmith] from comment #15) > I need a better understanding of this bug. > > Is this basically that on first run, certain apps can't be uninstalled? Post > first run after a reboot, they can be? Yes, that is the issue, after rebooting, apps can be deleted as they should be.
(In reply to Daniel Coloma:dcoloma from comment #16) > (In reply to Jason Smith [:jsmith] from comment #15) > > I need a better understanding of this bug. > > > > Is this basically that on first run, certain apps can't be uninstalled? Post > > first run after a reboot, they can be? > > Yes, that is the issue, after rebooting, apps can be deleted as they should > be. Ah. That probably explains what happened over in bug 875066.
Keywords: verifyme
QA Contact: jsmith
I gonna add some tests in bug 876623
Verified on a 5/30 Partner Build by checking that apps were uninstallable on initial flash + one reboot.
This issue no longer reproduces on Leo V1.1 User is able to delete apps on first run, and also post first run after a reboot. Leo build Mozz 1.1: 20130529070208 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/6ca32ed2bbc6 Gaia: 8f5ab7bfd4a2921aab4e2de11e0d79a29c1bb062
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: