Closed
Bug 1118699
Opened 10 years ago
Closed 9 years ago
Follow up of Bug 1031094 - [Collection] Removing an e.me app from the homescreen also removes it from the top of the collection
Categories
(Firefox OS Graveyard :: Gaia::Everything.me, defect)
Tracking
(blocking-b2g:-, b2g-v2.0 unaffected, b2g-v2.0M unaffected, b2g-v2.1 affected, b2g-v2.1S affected, b2g-v2.2 affected, b2g-master affected)
RESOLVED
WONTFIX
blocking-b2g | - |
Tracking | Status | |
---|---|---|
b2g-v2.0 | --- | unaffected |
b2g-v2.0M | --- | unaffected |
b2g-v2.1 | --- | affected |
b2g-v2.1S | --- | affected |
b2g-v2.2 | --- | affected |
b2g-master | --- | affected |
People
(Reporter: whsu, Unassigned)
References
Details
(Keywords: regression, Whiteboard: [systemsfe])
+++ 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
Reporter | ||
Comment 1•10 years ago
|
||
[Blocking Requested - why for this release]:
A follow up of Bug 1031094.
Bad user experience.
blocking-b2g: --- → 2.1?
See Also: → 1031094
Comment 2•10 years ago
|
||
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+
Flags: needinfo?(chrislord.net)
Updated•10 years ago
|
Keywords: regressionwindow-wanted
Comment 3•10 years ago
|
||
Let's get a branch check first then get a regression window.
Keywords: qawanted
Updated•10 years ago
|
QA Contact: ychung
Comment 4•10 years ago
|
||
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.
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.0:
--- → unaffected
status-b2g-v2.1:
--- → affected
status-b2g-v2.2:
--- → affected
status-b2g-master:
--- → affected
Flags: needinfo?(ktucker)
Keywords: qawanted
Comment 5•10 years ago
|
||
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
Keywords: regressionwindow-wanted
Comment 6•10 years ago
|
||
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)
Comment 7•10 years ago
|
||
[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?
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Comment 8•10 years ago
|
||
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.
Flags: needinfo?(crdlc)
Comment 9•10 years ago
|
||
(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?
Flags: needinfo?(jsavory)
Comment 10•10 years ago
|
||
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)
Updated•10 years ago
|
status-b2g-v2.0M:
--- → unaffected
status-b2g-v2.1S:
--- → affected
Comment 12•10 years ago
|
||
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)
Comment 13•10 years ago
|
||
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).
Flags: needinfo?(kcaldwell)
Comment 14•10 years ago
|
||
Just to clear an ambiguity: Are regular bookmarks also considered as apps in this case? What should be the behavior raised in bug 1059095?
Flags: needinfo?(kcaldwell)
Comment 15•10 years ago
|
||
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.
Flags: needinfo?(kcaldwell)
Comment 16•9 years ago
|
||
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: 9 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•