1147148 - Bring tab swipe deletion closer to designed interaction

Status: RESOLVED FIXED

(Firefox for iOS :: General, defect)

Description

[Darrin Henein [:darrin]]

Attachment: Full Bleed - Delete.png

Swiping a tab should feel more dynamic and should not involve the default 'Remove' confirmation that UITableView/CollectionView offers.

Swiping the tab past a threshold should animate the tab away and delete it.

I will work to better define this interaction, but we can probably start moving away from the table view swipe behaviour.

*ignore the tab and visual design in the attached mockup

Comment 1

[Stephan Leroux]

Mind if I take this one? I have a partial implementation I've started to work on.

Comment 2

[Wesley Johnston (:wesj)]

Take it!

Comment 3

[Stephan Leroux]

Attachment: Pull Request

First pass at tab deletion

Comment 4

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Attachment: PR: https://github.com/mozilla/firefox-ios/pull/293

This is the same patch that :sleroux originally submitted with two small changes that I made.


From Gitub:

I moved this branch to #293 so that I could add an additional change to it. I did two things:

*    To fix the offset issue I assigned self.startLocation to self.animatingView.center instead of self.originalCenter.

*    I changed the logic to decide if the tab should bounce back or not a little bit. Previously it was possible to slowly move the tab to the left or right and then upon release it would slowly continue moving off the screen. I changed it so that is now takes the velocity into account. You really have to give the tab a push AND be past the treshold. Otherwise it just bounced back.

Comment 5

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Merged this. I am marking this as resolved. We will need to file a new bug for the work to move the tabstraycontroller to use a UICollectionView. That work can also include updates to this code.