Open Bug 941546 Opened 11 years ago Updated 2 years ago

[Australis] Make the tab animation more fluid and continuous

Categories

(Firefox :: Tabbed Browser, defect)

Product:
Firefox
Component:
Tabbed Browser
Type:
defect

Tracking

()

People

(Reporter: Optimizer, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [Australis:P-])

The current behavior of tab animation in Australis. Assume my tab strip be (sorry for making it look a little like chrome, blame ASCII) : _________________ ________________ ________________ | / [selected] \ + Right now if i click on the new tab button, the [selected] tab becomes background one, and a new tab starts expanding with initial width being 0. Now since the australis tabs have their border overlapping and non vertical (curved), starting a tab expand animation from 0 width makes the curve shape distort until an initial width is achieved (this width is somewhat closer to new tab button hover state width) when the shape is restored to its normal shape. Due to this, for the time the curve shape is not fully restored, it is above the (previously) selected tab. This phenomena is visible in current nightly too. The new tab opening animation starts from over the last tab opened. bug 940262 tries to fix this visual glitch by hiding the tab initially and showing it only when the tab is not overlapping the last opened tab. While it removes the visual glitch to most extent, the animation does not look continuous and fluid to me and I think it can be improved: Assume the workflow of opening a tab using mouse click on new tab button. So the new tab button already has the hover shape , and thus it has the curvy borders too. Now as soon as the user clicks this button, instead of starting the new tab opening animation from 0 width, why not starting it from an initial width such that the shape of the initial position is exactly like the new tab hover state shape. Everything else will be as is, just the starting width will be such that it mimics the shape of new tab button. What are the benefits you think ? 1) The whole process of opening a new tab from click will feel continuous. 2) No initial overlapping of tabs. 3) since the user clicked the new tab button, previously, the animation he was getting was : initial position: certain width of new tab, shortly after that: 0 width, final position: full tab width. Now, it will be : initial position: new tab width. final position: full tab width. 4) Should be a little faster (?) since we are animating less.
Blocks: australis-merge, australis-tabs
OS: Windows 7 → All
Hardware: x86_64 → All
Marking as P- for now since this seems like it is still in the idea stages.
Whiteboard: [Australis:P-]
I think the idea stage is over. I have explained what i wanted. Tim was interested in giving this a shot. Tim , what say ?
Flags: needinfo?(ttaubert)
Using the initial size of the new tab "tab" was part of the original tab animation spec: http://www.stephenhorlander.com/files/animation/Firefox-4-Animation-i01-%28Win7%29-%28NewTab%29-v01.html
(In reply to Girish Sharma [:Optimizer] from comment #2) > I think the idea stage is over. I have explained what i wanted. Tim was > interested in giving this a shot. > Tim , what say ? Yeah, I'm not quite satisfied with the current animation and shorlander's proposal seems to be what you and I had in mind, right? Would be great if someone found time to try and address this.
Flags: needinfo?(ttaubert)
I also think that this kind of animation makes sense. Since the visuals changed quite a bit with australis, I suggest that we just fade in the plus icon once the animation is done (instead of the shift in shorlanders spec). We still need a backup plan for the case where we have a tab overflow and the plus icon isn't integrated in the tab strip anymore. Fixing bug 943960 would give us that, but I do prefer the way that the text fades in in shorlanders spec. I'll try to come up with a spec that covers all those cases.
Currently we have five ways that tabs can appear: 1. After clicking the plus button next to the last tab 2. Using Ctrl+T (in which case there is no initial hover state of the plus button, but I think that won't be a problem) 3. After clicking the plus button or using Ctrl+T when in an overflow state 4. Opening a link in a new tab using Ctrl+click or the context menu (in this case a non-selected tab will appear) 5. Same as 4, but with the option to switch to the new tab immediately enabled Did I forget a case? I'm now working on the visuals.
The only case I think you missed was File > New Tab, and middle-clicking links (which is functionally equivalent to #4). Sounds like you got the rest.
There is another way, whose state is equivalent to state 2 (or 4) in comment 7 - Middle clicking on the empty space in tabs toolbar.
Alright, so here it is: http://phlsa.github.io/ff-tab-opening This should cover all the cases (some different methods of invocation have the same visual effect, eg. File > New Tab == Ctrl+T) Timing and motion curves can be found here: https://github.com/phlsa/ff-tab-opening/blob/master/css/transitions.css (you can ignore the .slow stuff)
Well, it turns out I did forget one subcase: When the tab bar is already full but not yet overflowing, the plus button stays in the same spot. The direction of the animation is reversed in this case and it should be treated a little differently. This should not influence the other cases and I'll add it to the spec tomorrow.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.