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?
** 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.
blocking-b2g: --- → 2.0?
blocking-b2g: 2.0? → 2.0+
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.
Summary: 3rd-party keyboard app would be shown on vertical homescreen after installation → Vertical home shows packaged apps before their role is fetched which displays hidden roles (keybaords, etc...) on first install until reboot
Created attachment 8444979 [details] [review] 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.
Attachment #8444979 - Flags: review?(kgrandon)
@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.
Attachment #8444979 - Flags: review?(kgrandon) → review+
Pretty sure this is an intermittent failure on try... waiting for re triggers before landing.
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.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
status-b2g-v2.0: --- → fixed
status-b2g-v2.1: --- → fixed
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
Status: RESOLVED → VERIFIED
status-b2g-v2.0: fixed → verified
status-b2g-v2.1: fixed → verified
You need to log in before you can comment on or make changes to this bug.