943960 - [Australis] When opening a new tab, the close icon appears too soon

Status: RESOLVED DUPLICATE of bug 979938

(Firefox :: Tabbed Browser, defect)

Description

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Attachment: first frames of tab open animation

See the first frame of the attachment.
Also, having the text dynamically truncated during the transition contributes to the animation looking a little wonky. We should just display the text when the animation is finished or, even better, fade it in.

Comment 1

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Quick demos:
http://phlsa.github.io/ff-tab-animation/

Comment 2

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Disregard everything but the animation itself from the demo. Spacing etc. isn't correct there.

Comment 3

[Allan Gardner (:Mathnerd314)]

I'd like to do this bug; can someone please assign it to me?

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Hey Allan!

Sure, I can. I should point out that it's possible that this bug is a regression caused by bug 944136, which might get backed out, but let's get you started on this and see where we get.

Do you have a development environment / build on OS X ready to go?

-Mike

Comment 5

[Allan Gardner (:Mathnerd314)]

I have a Windows environment which just finished building (after 6.7 hours). The bug is in that build too, so I'm thinking Platform -> All?

Comment 6

[Allan Gardner (:Mathnerd314)]

Watching https://bug940262.bugzilla.mozilla.org/attachment.cgi?id=8334416 a few times, it looks like the close button was shown early even before bug 940262, and that patch just made it a lot more obvious because the background is not drawn while the close button still is. (I'm guessing this was due to bug 919541?)

Bug 941546 wants to make the animation start with the initial tab and then expand, like in http://www.stephenhorlander.com/files/animation/Firefox-4-Animation-i01-%28Win7%29-%28NewTab%29-v01.html. Not certain if this is a duplicate of that or vice-versa.

ttaubert says "I would have liked to [hide] the .tab-close-button because it looks a little weird that this is now also sliding from left to right but it's not as easy due to it being display:none." I'm pretty certain that can be worked around as in http://msujaws.wordpress.com/2013/06/11/animating-and-transitioning-displaynone-elements/

So it looks like regardless of which patch sticks, this bug needs to be fixed...

Comment 7

[Mike Conley (:mconley) (:⚙️)]

Hey Dao,

Allan and I were just discussing this bug, and we were thinking this might be a lot easier if our CSS had some idea of when a tab was animating and when it was not.

What do you think of us modifying the tab binding to have it set an "animating" attribute on itself when opening or closing, which is removed once the transition completes? That'd make it much simpler to hide the close button (and label, if we want to go down that route) when the tab is animating.

Thoughts?

Comment 8

[Mike Conley (:mconley) (:⚙️)]

Or perhaps you have a thought on that, Tim?

Comment 9

[Tim Taubert [:ttaubert] (inactive)]

Wouldn't it also maybe easier to implement a better tabopen animation (see bug 941546) by using css animations instead of transitions?

Comment 10

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to Tim Taubert [:ttaubert] from comment #9)
> Wouldn't it also maybe easier to implement a better tabopen animation (see
> bug 941546) by using css animations instead of transitions?

The proposed animation in bug 941546 is great! I think this bug is still relevant for the cases where the plus button is not directly next to the last tab (overflow).

Comment 11

[Allan Gardner (:Mathnerd314)]

(In reply to Philipp Sackl [:phlsa] from comment #10)
> (In reply to Tim Taubert [:ttaubert] from comment #9)
> > Wouldn't it also maybe easier to implement a better tabopen animation (see
> > bug 941546) by using css animations instead of transitions?
> 
> The proposed animation in bug 941546 is great! I think this bug is still
> relevant for the cases where the plus button is not directly next to the
> last tab (overflow).

We don't do any animation of the tab itself during overflow (it just appears). So this bug isn't relevant for that case.

The mockup for bug 941546 doesn't show the close button at all, so I'm going to dupe to that bug and do whatever UI fixes are needed there.