+++ This bug was initially created as a clone of Bug #1031094 +++ @ Description: This bug can be reproduced on latest Flame v2.1 build. When user removes an e.me app from the homescreen, Firefox OS also removes it from the top of the collection. @ STR 1. Open a Smart Collection 2. Add a e.me app to the homescreen 3. Add it to the top of the Smart Collection 4. Go to the homescreen and remove it. 5. Go back to the collection @ Demo video - https://bugzilla.mozilla.org/attachment.cgi?id=8531164 @ Actual result The app is moved back with the other. Worst case, if the Internet connection is off while removing the bookmark on the homescreen, the icon is no more present. @ Build information - Gaia-Rev b04a8cb7b2482e0a44e6702b48c42283a00b5b1e - Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/99cea2c818f6 - Build-ID 20150106001308 - Version 34.0 - Device-Name flame - FW-Release 4.4.2 - FW-Incremental eng.cltbld.20150106.034709 - FW-Date Tue Jan 6 03:47:20 EST 2015 - Bootloader L1TC10011880
[Blocking Requested - why for this release]: A follow up of Bug 1031094. Bad user experience.
blocking-b2g: --- → 2.1?
See Also: → 1031094
BLocking given this is a follow-up regression from a blocking bug that probably didnt fix the issues (https://bugzilla.mozilla.org/show_bug.cgi?id=1031094). :cwiiis can you please help with this ?
blocking-b2g: 2.1? → 2.1+
Let's get a branch check first then get a regression window.
This issue also reproduces on Flame 2.2 and 3.0. Result: The icon is removed from the top of the Smart Collection after the icon is deleted from the homescreen. Environmental Variables: Device: Flame 2.2 BuildID: 20150114140141 Gaia: 7c5b27cad370db377b18a742d3f3fdb0070e899f Gecko: ce27f2692382 Gonk: Could not pull gonk. Did you shallow Flash? Version: 37.0a2 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 Device: Flame 3.0 BuildID: 20150115051932 Gaia: ebc90190771a945d405f5d36efd813db6f77f965 Gecko: 206bf1a98cd7 Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 ------------ This issue does NOT occur on Flame 2.0. Result: The icon still exists at the top of the Smart Collection after the icon is deleted from the homescreen. Environmental Variables: Device: Flame 2.0 BuildID: 20150114234232 Gaia: 736933b25ded904f0cb935a0d48f1f3cf91d33ad Gecko: 8ff0d933175c Version: 32.0 (2.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 ------------ I'll be working on the regression window next.
b2g-inbound Regression Window: Last Working Environmental Variables: Device: Flame 2.1 BuildID: 20140827212049 Gaia: 553f7969241ddcd592ac53f25a46230475b87c49 Gecko: 0e901b079a7c Version: 34.0a1 (2.1) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 First Broken Environmental Variables: Device: Flame 2.1 BuildID: 20140827234548 Gaia: 423a88c7bbcbecd01cbd7197992aed189726651f Gecko: 51d52efc1a05 Version: 34.0a1 (2.1) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Last Working Gaia First Broken Gecko: Issue NOT reproduce Gaia: 553f7969241ddcd592ac53f25a46230475b87c49 Gecko: 51d52efc1a05 First Broken Gaia Last Working Gecko: Issue DOES reproduce Gaia: 423a88c7bbcbecd01cbd7197992aed189726651f Gecko: 0e901b079a7c https://github.com/mozilla-b2g/gaia/compare/553f7969241ddcd592ac53f25a46230475b87c49...423a88c7bbcbecd01cbd7197992aed189726651f caused by bug 1059095
Hey Cristian, do you have time to take a look at this? I'm pretty caught up in various bugs atm.
Flags: needinfo?(chrislord.net) → needinfo?(crdlc)
[Blocking Requested - why for this release]: Well bug 1059095 was actually done to implement this as the expected behavior. I assume that's what we did with the previous home screen as well in 1.4. Since this is the case we might just want to mark this as resolved/wontfix. I don't think this is a blocker though, since technically this is how we decided to implement it. Because of that I'm sending it back into triage. Our original reasons for blocking no longer hold.
blocking-b2g: 2.1+ → 2.1?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Chris, I was reviewing those months but for making patches I don't have time because I am focus on FxHello app nowadays. Sorry (In reply to Chris Lord [:cwiiis] from comment #6) > Hey Cristian, do you have time to take a look at this? I'm pretty caught up > in various bugs atm.
(In reply to Kevin Grandon :kgrandon [INACTIVE - heads down on Gij Issue] from comment #7) > Well bug 1059095 was actually done to implement this as the expected > behavior. We might need some UX input to make sure to know which one is the expected behavior. Jacqueline, could you help us out?
I'm going to pass the ni? to Francis as I believe he is the UX lead on this feature. However, I do think that Kevin might be right in comment 7, that this feature is implemented as designed. Francis, can you confirm?
Flags: needinfo?(jsavory) → needinfo?(fdjabri)
Decided to minus it.
blocking-b2g: 2.1? → -
This is more of a home screen issue, not related to search, so I don't have background here. Where we go here will depend on whether we see Smart Collections as being independent from the installed apps or whether they are tied together. Could you confirm, Katie?
Flags: needinfo?(fdjabri) → needinfo?(kcaldwell)
UX Recommendation: The user took 2 separate, intentional actions to add the app to 2 separate locations: 1. "Add to home screen" 2. "Add to top of collection" Therefor, the user action of "delete" from a specific location (home screen) should NOT remove the app from the 2nd location (top of collection).
Just to clear an ambiguity: Are regular bookmarks also considered as apps in this case? What should be the behavior raised in bug 1059095?
Yes, this is also an issue. I've chatted with a few other UXers about this, to make sure we're all agreed. Bug 1059095 - is very similar to this bug and so is our ux recommendation. Bookmarks and apps look the same to the user, they likely can not tell the difference. In the STR in 1059095, the user is essentially making a copy of Google App/Bookmark into a Smart Collection. The user actively dragged the Google icon, while in edit mode, to a Smart Collection (saw the "+" icon), dropped the icon, which then returns to it's original placement and remains on the home screen. (They did not move the icon, they made a duplicate.) Because the user took 2 separate actions (1. Add to Home Screen 2. Drag copy to Smart Collection), it would then be unexpected, when deleting one icon, either from the Smart Collection or the home screen, for the other icon to disappear. The primary UX concern is that they user doesn't know the difference between icons (copy or alias) and their expectation of deleting one should not be destructive of the other.
Mass update: Resolve/Wontfix all existing collections bugs as this feature is now removed. Please re-open or file a new bug if you feel that this bug still exists in master.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.