1029329 - Vertical home shows packaged apps before their role is fetched which displays hidden roles (keybaords, etc...) on first install until reboot

Status: VERIFIED FIXED

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

Description

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

STR
===
1. Go to marketplace to install one of the 3rd-party keyboards, say,
   https://marketplace.firefox.com/app/greek-alphabet-keyboard?src=search

2. Go back to vertical homescreen.

Expected: Cannot see the icon for the 3rd-party keyboard we just installed.
Actual: it would shown.

        Note: the icon would *not* be shown after reboot.
        So, I think the "role" property should be correct here so that it could be filtered out after reboot?

Comment 1

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

** For Triage **
Nominate 2.0? since enabling 3rd-party keyboard is one of the key features in v2.0.
And the workaround for this issue is to reboot the phone, which is not a common action for current smart phone users.

Comment 2

[James Lal [:lightsofapollo]]

The main problem here (in particular with the app mentioned above) is when installing a packaged app we do not have the full manifest and only the full manifest contains the .role attribute which determines if the app should be shown on the homescreen... This is easily fixable by not packaged showing apps until they have fully downloaded (v1 homescreen approach) this makes me somewhat sad as the immediate indication is nice.

Options (this only applies to first time installs not updates):

 - (v1 approach) do not show packaged apps (maybe we can special case packaged apps not sure) on the homescreen until they are fully downloaded

 - Show app download in progress and once it has been installed if it is a "hidden" app (like keybaords) remove it from the homescreen.

Neither is difficult and is purely a UX decision.

Comment 3

[James Lal [:lightsofapollo]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/20917

This is the second option I described where we show the icon until we know it is supposed to be hidden (then remove it). Even if we land this it will not prevent us from adding the other logic easily.

Comment 4

[James Lal [:lightsofapollo]]

@jsavory see #2 I have also opened bug 1029349 (people seem positive so far) which would remove the need for workarounds but we need a solution for 2.0 timeframe.

Comment 5

[James Lal [:lightsofapollo]]

Pretty sure this is an intermittent failure on try... waiting for re triggers before landing.

Comment 6

[Jacqueline Savory [:jsavory] UX]

I think in this case we can go with the more likely scenario - which is the user is downloading an app. I feel that its important for users to be able to see that an app is downloading and I don't think we should restrict that for the potential keyboard scenario. 

I would recommend the second option.

Comment 7

[James Lal [:lightsofapollo]]

glad we agree! https://github.com/mozilla-b2g/gaia/commit/756f1ae83413fe6bf5e8b6f985fb03da1bab02d4

Comment 8

[Ryan VanderMeulen [:RyanVM]]

v2.0: https://github.com/mozilla-b2g/gaia/commit/f169f0c45bcf241df40edc5b341dd3f3f680be98

Comment 9

[Coler]

This issue has been verified successfully on Flame2.1&2.0.
Reproducing rate: 0/5
See attachment: Verify_Flame_Thirdkeyboard.mp4

Flame2.0 build version:
Gaia-Rev        856863962362030174bae4e03d59c3ebbc182473
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/e40fe21e37f1
Build-ID        20141208000206
Version         32.0

Flame2.1 build version:
Gaia-Rev        38e17b0219cbc50a4ad6f51101898f89e513a552
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/8b92c4b8f59a
Build-ID        20141205001201
Version         34.0

Comment 10

[Coler]

Attachment: Verify_Flame_Thirdkeyboard.MP4