Closed
Bug 1119650
Opened 10 years ago
Closed 10 years ago
(app-grouping) When moving a group unsuccessfully, the group moves back but the screen does not scroll to that place.
Categories
(Firefox OS Graveyard :: Gaia::Homescreen, enhancement)
Tracking
(b2g-v2.2 verified, b2g-master verified)
VERIFIED
FIXED
2.2 S7 (6mar)
People
(Reporter: hcheng, Assigned: cwiiis)
References
Details
(Keywords: polish, Whiteboard: [systemsfe])
Attachments
(2 files)
(deleted),
text/x-github-pull-request
|
kgrandon
:
review+
tif
:
ui-review+
bajaj
:
approval-gaia-v2.2+
|
Details |
(deleted),
video/mp4
|
Details |
*Description: When dropping a group into the middle of another group, the group moves back to its original place but the screen does not scroll to that place. *Steps: 1. 2 groups: 1 collapsed group(a) and 1 expanded big group(b). 2. enter Homescreen edit mode 3. long tap group(a) to move it 4. drag group(a) though the expanded group(b) 5. drop group(a) before reach the edge of group(b) *Expected results: After step 5, group(a) moves back to its original place, and screen scrolls to that place *Actual results: After step 5, group(a) moves back to its original place, and screen does not scroll
Reporter | ||
Comment 1•10 years ago
|
||
The recorded steps: https://www.youtube.com/watch?v=Caj9GbS60nQ&feature=youtu.be Dropping a group to the middle of a group is common. So, I think it is worth to discuss which behavior is better.
Flags: needinfo?(kcaldwell)
Flags: needinfo?(chrislord.net)
Reporter | ||
Updated•10 years ago
|
Blocks: app-grouping
Whiteboard: [systemsfe]
Updated•10 years ago
|
Severity: normal → enhancement
Assignee | ||
Comment 2•10 years ago
|
||
This is not specced behaviour, so removing the blocking bug. While I'm dubious as to whether this is common behaviour, I think scrolling to focus the thing you just dragged makes sense, and wouldn't be hard to implement - I like the idea, but I defer to UX. If we decide to implement this, I'd say this is a polish bug.
No longer blocks: app-grouping
Flags: needinfo?(chrislord.net)
Agreed. If a group is moved unsuccessfully, the user should see where it ends up, as moving the group was their primary action. Having the group snap back to a (possibly) unseeable position will likely cause confusion for the user. Keep spatial context by animating/scrolling the screen back to original group location. (UX spec will be updated.)
Flags: needinfo?(kcaldwell)
Assignee | ||
Updated•10 years ago
|
Comment 4•10 years ago
|
||
Hey Chris - what's the word on the bug fix for this one?
Flags: needinfo?(chrislord.net)
Assignee | ||
Comment 5•10 years ago
|
||
(In reply to Tiffanie Shakespeare from comment #4) > Hey Chris - what's the word on the bug fix for this one? I've not gotten to fixing this yet - It's on my list though (anything I intend to get to soon-ish I assign to myself)
Flags: needinfo?(chrislord.net)
Assignee | ||
Comment 6•10 years ago
|
||
I have (what I think is) a decent patch that fixes this, but getting it to scroll smoothly into position is proving tricky (tricky = I've not managed it yet and I'm beginning to get concerned that it may not be possible without more drastic changes). How would you feel about this feature if the scroll position jumped to the icon you were dragging as opposed to scrolling smoothly to it? Personally, I wonder if it's worth doing if it compromises the experience like that, I just want to know if you think differently. We will eventually have everything smooth, this is a question of do we want this now, but sub-optimal, or later and better?
Flags: needinfo?(tshakespeare)
Comment 7•10 years ago
|
||
It's hard to say without seeing the patch, but I echo Katie's concerns that by not showing where the group ended up it could cause user confusion. Additionally, since their task was to do something with that group, not showing it causes the user to go hunt for it to complete the task the were trying to do. Not showing were the group ended up is usability flaw that needs to be fixed. But like I said without seeing how the patch is it's hard to say if the jumping is more or less confusing.
Flags: needinfo?(tshakespeare)
Assignee | ||
Comment 8•10 years ago
|
||
Here's the branch where I have it implemented - currently, it just jumps immediately to the nearest position that can show the moved icon: https://github.com/Cwiiis/gaia/tree/bug1119650-focus-moved-items Seeing some really bad performance when dragging groups atm, so might have to fix that before this is really testable... Seems we're badly hit by some platform changes to will-change and we need to restructure things a little...
Comment 9•10 years ago
|
||
Assignee | ||
Comment 10•10 years ago
|
||
Comment on attachment 8572642 [details] [gaia] Cwiiis:bug1119650-focus-moved-items > mozilla-b2g:master Well, ends up I got the smooth scrolling in... :)
Attachment #8572642 -
Flags: review?(kgrandon)
Comment 11•10 years ago
|
||
Comment on attachment 8572642 [details] [gaia] Cwiiis:bug1119650-focus-moved-items > mozilla-b2g:master Nice job, this works for me. I imagine integration tests for something like this is quite painful. I wonder if it's worth a unit test though?
Attachment #8572642 -
Flags: review?(kgrandon) → review+
Comment 12•10 years ago
|
||
Comment on attachment 8572642 [details] [gaia] Cwiiis:bug1119650-focus-moved-items > mozilla-b2g:master very nice dude!
Attachment #8572642 -
Flags: ui-review+
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Updated•10 years ago
|
Keywords: checkin-needed
Comment 14•10 years ago
|
||
Pull request has landed in master: https://github.com/mozilla-b2g/gaia/commit/3af6d4a04e4b4ccc40f404cd5f25fa76e2dce516
Updated•10 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 15•10 years ago
|
||
Comment on attachment 8572642 [details] [gaia] Cwiiis:bug1119650-focus-moved-items > mozilla-b2g:master [Approval Request Comment] [Bug caused by] (feature/regressing bug #): [User impact] if declined: Confusing behaviour when dragging a group to a far-away position where it can't be dropped [Testing completed]: Manual testing, covered by 2 unit tests and regressions hopefully covered by lots of existing tests. The actual change is also quite small and implemented in a reasonably unobtrusive fashion. [Risk to taking this patch] (and alternatives if risky): Low. [String changes made]: None
Attachment #8572642 -
Flags: approval-gaia-v2.2?
Updated•10 years ago
|
Attachment #8572642 -
Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
Comment 16•10 years ago
|
||
v2.2: https://github.com/mozilla-b2g/gaia/commit/07fab8aa33a9eb1fb70ac0ee0c4b1a9c0b34b1c3
Comment 17•10 years ago
|
||
This problem is verified pass on latest build of Flame 2.2 and Flame 3.0. See attachment: Verify_video.MP4 Rate:0/5 Flame 2.2 build: Build ID 20150311002522 Gaia Revision 3f032238a52f08e4c2f68a47ad065a96eb22d470 Gaia Date 2015-03-11 00:28:07 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/004fa1cb1dd4 Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150311.040546 Firmware Date Wed Mar 11 04:05:57 EDT 2015 Bootloader L1TC000118D0 Flame 3.0 build: Build ID 20150311010231 Gaia Revision 943c8b4039f59b08ba100390e164a076a20c892e Gaia Date 2015-03-10 20:35:07 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/fd8e079d6335 Gecko Version 39.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150311.043838 Firmware Date Wed Mar 11 04:38:50 EDT 2015 Bootloader L1TC000118D0
You need to log in
before you can comment on or make changes to this bug.
Description
•