1369701 - Tab Reorder - Sliding left and right will close the tab

Status: RESOLVED INVALID

(Firefox for Android Graveyard :: General, defect, P2)

Description

[Ioana Chiorean]

Steps:
1. Have several tabs open
2. Open tabs view 
3. Try to slide left or right all tabs 

Expected Results:
- sliding left or right should move the tab 1 position to the left or to the right

Actual Rights:
- some tabs (can't figure out exactly why some of them only) will become transparent will close when slided left or right


Logs: 
06-02 14:54:06.648: D/GeckoToolbar(7096): onTabChanged: MOVED
06-02 14:54:06.648: D/GeckoBrowserApp(7096): BrowserApp.onTabChanged: 3: MOVED
06-02 14:54:12.865: D/GeckoToolbar(7096): onTabChanged: CLOSED
06-02 14:54:12.866: D/GeckoBrowserApp(7096): BrowserApp.onTabChanged: 6: CLOSED
06-02 14:54:12.866: D/MediaControlService(7096): onStateChanged, state = STOPPED
06-02 14:54:17.794: D/GeckoToolbar(7096): onTabChanged: CLOSED
06-02 14:54:17.796: D/GeckoBrowserApp(7096): BrowserApp.onTabChanged: 3: CLOSED
06-02 14:54:17.796: D/MediaControlService(7096): onStateChanged, state = STOPPED

See video: https://youtu.be/aFJmb8i9-Ok

Comment 1

[Ioana Chiorean]

Some more debugging on the way - I think on some times the long pressed is not registered correctly and it considered a panning only: https://youtu.be/U7mG7rWG9QI
Maybe adding some haptic feedback to know u did correctly long pressed it or not?

Comment 2

[Tom Klein]

(In reply to Ioana Chiorean from comment #1)
> I think on some times the long pressed is
> not registered correctly and it considered a panning only:
> https://youtu.be/U7mG7rWG9QI

Right, in order to initiate a drag-reorder you have to long press first.  If you start the "drag" at any point prior to a long press the behavior you get is swipe-to-close (as it was prior to the reorder tabs work), which is why you see the tab become transparent and sometimes close depending on how swipey the motion is.  That all looks like it's working as expected in the videos.

> Maybe adding some haptic feedback to know u did correctly long pressed it or
> not?

It looks like ItemTouchHelper calls for haptic feedback on a long press:
https://github.com/android/platform_frameworks_support/blob/master/v7/recyclerview/src/android/support/v7/widget/helper/ItemTouchHelper.java#L658
and I'm getting that feedback on my GS4 5.0.1 device, so I'm not sure why you weren't getting the long press feedback.  Do you get feedback for other interactions?  Could it be turned off on your device?

Comment 3

[Tom Klein]

Closing this as invalid since all the behavior I'm seeing in the videos is expected behavior, as described in comment 2.

Ioana, if you could try some more devices to see if you're getting haptic feedback when a long press occurs (and maybe check if haptic feedback is turned on on the device you were using in your earlier comments) and file a new bug if you're not getting it, that would be great.  As I mentioned in comment 2, as far as I can tell Android is requesting haptic feedback for us on the long press in this situation, but I only have one device to test that on, and it works on that device. (Emulators don't seem to provide any sort of cue when haptic feedback occurs, so they're no help here).

Comment 4

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

NI Jack to look at this from UX perspective.

Comment 5

[Jack Lin[:jacklin]]

For UX perspective, this implementation is easy to use and already has visual hint to users. But, if I am picky abut the design, I think we can enhance the visual hint to let users know about the current status or mode. 

Can we receive users feedback about this? If we can receive many users complains about this design, we can start to redesign it.

This is my thought. How do you think?

Comment 6

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

We wouldn't get much feedback w/o having it shipped to beta.
This should not block shipping.