1259803 - Add multistep animations for panel opening

Status: NEW

(Toolkit :: UI Widgets, defect)

Description

[Jared Wein [:jaws] (please needinfo? me)]

The panels in Firefox that have animate="open" open from transform: scale(.4) to scale(1) while also moving opacity from 0 to 1. This is a subtle animation but it not natural. As these panels "hang" from an anchor, it is more natural if they moved just a bit past their destination before settling at their destination point.

Comment 1

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: WIP Patch

Note that these arrow panels appear in their own window and are clipped when extended outside of their bounding rectangle, which is why I needed to increase the padding on the panel so the bounding rect wouldn't clip.

This patch works best for the menu panel, the padding isn't on the right side for the control center panel, which is currently showing the clipping. This can be trivially fixed by moving the inline padding based on the arrow_position.

Neil: with the menu panel, extra area is added to the bottom of the #PanelUI-contents-scroller around the time that we move to the second step of the transition animation. Do you have any ideas as to why this is happening?

Stephen: I remember there being specs for panel animations that Philipp had made a while back. Do you know where those are still, and/or do you have some feedback on this?

Here is a screencast of the patch, http://screencast.com/t/rq2O7ACS

Comment 2

[:Gijs (he/him)]

Comment on attachment 8734852 [details] [diff] [review]
WIP Patch

Review of attachment 8734852 [details] [diff] [review]:
-----------------------------------------------------------------

So, I would love for our animations to be "better".

But I'm worried that we need to spend time analyzing why they're janky first, before changing them like this (which looks set to make them *more* rather than less janky, given that the animation is more complex).

::: toolkit/content/xul.css
@@ +451,5 @@
>  
>  %ifndef MOZ_WIDGET_GTK
>  
>  panel[type="arrow"]:not([animate="false"]) {
> +  transform: scale(.4) rotateZ(-15deg);

This takes the existing animation and makes it more complex. Considering we have bug 1252224 already on file, I don't think adding complexity to the animation without understanding why the current transition is janky is the best way to improve the situation. :-(

@@ +456,3 @@
>    opacity: 0;
>    transition-property: transform, opacity;
> +  transition-duration: .15s;

Because there are now 2 animations with this duration, this effectively doubles the time we spend animating, right? I'm worried that will make things seem slower to users.

::: toolkit/themes/linux/global/popup.css
@@ +39,5 @@
>    margin-bottom: -16px;
>  }
>  
> +panel[type="arrow"]:not([animate="false"]) {
> +  padding-bottom: 125px;

Where did you get these numbers? Presumably if the panel is big enough "even" these aren't going to be large enough?

Comment 3

[Stephen Horlander [:shorlander]]

Comment on attachment 8734852 [details] [diff] [review]
WIP Patch

Review of attachment 8734852 [details] [diff] [review]:
-----------------------------------------------------------------

I tried this but it was hard to evaluate because panel animations are so visibly janky at the moment. On OS X they are particularly bad.

Perf issues aside I think the panel animation we have now are nice because they are relatively fast and mostly subtle but still convey where they are coming from.

Before we consider changing it I think we should have a more thoughtful discussion around what we want out of animations in general and how that is reflected consistently throughout Firefox.

Comment 4

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

Comment on attachment 8734852 [details] [diff] [review]
WIP Patch

Removing my feedback flag since Stephen has already provided feedback.