[User Story] Grouping of New Apps

VERIFIED FIXED in 2.2 S2 (19dec)


5 years ago
5 years ago


(Reporter: pdol, Unassigned)



2.2 S2 (19dec)
Dependency tree / graph

Firefox Tracking Flags

(feature-b2g:2.2+, b2g-master verified)


(Whiteboard: [ucid: ][ft:systemsfe])

User Story

As a user I want newly installed apps/bookmarks to be added to a group on homescreen which hasn't already been organized so that my content organization remains intact.

Acceptance Criteria:
1. When an app is installed or a bookmark added to the homescreen, the app is added to a group as described by the UX spec, not an existing group that has already been organized.
2. Interaction and visuals match UX spec.


(1 attachment)

No description provided.
Depends on: 1091007
Closed: 5 years ago
Resolution: --- → FIXED
Hi Chris,
I found this bug conflicts with Bug 1102220. Current behavior follows Bug 1102220, so I guess this story is invalid. Is my understanding correct?
Flags: needinfo?(chrislord.net)
(In reply to Hermes Cheng[:hermescheng] from comment #1)
> Hi Chris,
> I found this bug conflicts with Bug 1102220. Current behavior follows Bug
> 1102220, so I guess this story is invalid. Is my understanding correct?

Yes, I believe so.
Flags: needinfo?(chrislord.net)
feature-b2g: 2.2? → 2.2+
Target Milestone: --- → 2.2 S2 (19dec)
Issue verified fixed on Flame 3.0

Adding apps from Marketplace and bookmarks from Browser works as expected. The new icon is added to the bottom-most app grouping no matter the configuration of the group. In LTR languages the existing and new app icons are left aligned, in RTL the existing and new app icons are right aligned. If the group is collapsed, the group expands and the new icon is added to the previously collapsed group on return to homescreen. If the last available group was already expanded, it stays expanded. If all app groups are collapsed, only the app grouping where the app was added to is expanded, the rest of the groups remain collapsed. All of these were checked on LTR as well as RTL languages.

Device: Flame 3.0 Master
Build ID: 20150209010211
Gaia: 0d7b35f23402c4cb29bca6b98280fec48a196dec
Gecko: 3436787a82d0
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Adding verifyme for 2.2 verification.
Keywords: verifyme
According STR in Comment 3, This issue has been verified successfully on latest Flame2.2.
Verify video:"Verify_1069696.MP4".

Flame 2.2 build:
Build ID               20150209002504
Gaia Revision          e827781324cbde91d2434b388f5dead3303a85ee
Gaia Date              2015-02-06 20:54:14
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/0552759956d3
Gecko Version          37.0a2
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150209.040038
Firmware Date          Mon Feb  9 04:00:51 EST 2015
Bootloader             L1TC000118D0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.