1431893 - CSS translate with transition and overflow creates jumpy animation

Status: RESOLVED DUPLICATE of bug 1428693

(Core :: DOM: Animation, defect)

Description

[Billy Noah]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20180103231032

Steps to reproduce:

Create a div with translate x axis is greater than the width of the div and both overflow and transition properties set.  Reference Stackoverflow question:
https://stackoverflow.com/questions/48352336/css-translate-with-transition-creates-jumpy-animation-in-firefox

Markup:

<style>
div.wrapper {
  transform: translate(100px, 0px);
  overflow: hidden;
}
div.block {
  color: #fff;
  background-color: #d9534f;
  transition: background-color 0.3s ease-in-out;
  width: 100px;
  height: 100px;
}
div.block:hover {
  background-color: #c9302c;
}
</style>
<div class="wrapper">
  <div class="block"></div>
</div>


Actual results:

The transition effect is very choppy. Tested in other browsers and looks fine everywhere else. This is also somehow tied in with the overflow setting because if I remove it everything is fine.


Expected results:

Smooth transition.

Comment 1

[Hiroyuki Ikezoe (:hiro)]

This seems to be a regression by bug 1166500.

Comment 2

[Hiroyuki Ikezoe (:hiro)]

(In reply to billynoah from comment #0)
> 
> <style>
> div.wrapper {
>   transform: translate(100px, 0px);
>   overflow: hidden;
> }
> div.block {
>   color: #fff;
>   background-color: #d9534f;
>   transition: background-color 0.3s ease-in-out;
>   width: 100px;
>   height: 100px;
> }
> div.block:hover {
>   background-color: #c9302c;
> }
> </style>
> <div class="wrapper">
>   <div class="block"></div>
> </div>

The GetVisualOverflowRectRelativeToSelf() for this 'block' div is (0,0,6000,6000). That seems to be correct.

The scrollableParent in IsFrameScrolledOutOfView is the 'wrapper' div.  The scrollableRect size which is got by calling scrollableParent->GetVisualOverflowRect() is (6000,0,35640,6000).  This seems to be incorrect, it should be (0, 0, 35640, 6000) which does not take into the transform style value 'translate(100px, 0px)', IIUC.  So we should use GetVisualOverflowRectToSelf() for scrollableParent. 

I've been trying to learn frame size things, there are still lots of things what I need to learn. :)

Comment 3

[Matt Woodrow (:mattwoodrow)]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #2) 
> The GetVisualOverflowRectRelativeToSelf() for this 'block' div is
> (0,0,6000,6000). That seems to be correct.
> 
> The scrollableParent in IsFrameScrolledOutOfView is the 'wrapper' div.  The
> scrollableRect size which is got by calling
> scrollableParent->GetVisualOverflowRect() is (6000,0,35640,6000).  This
> seems to be incorrect, it should be (0, 0, 35640, 6000) which does not take
> into the transform style value 'translate(100px, 0px)', IIUC.  So we should
> use GetVisualOverflowRectToSelf() for scrollableParent. 
> 
> I've been trying to learn frame size things, there are still lots of things
> what I need to learn. :)

That sounds expected. GetVisualOverflowRect returns a rectangle in the coordinate space of the parent of the current frame, and will be post-transform.

Comment 4

[Billy Noah]

Updated to Firefox 58.0 today and the issue seems to be improved, but still not quite right.  There is a clear difference beteween the smoothness of the transition when a wrapper is used to separate the `transform` and `overflow` properties as demonstrated in my answer here: https://stackoverflow.com/questions/48352336/css-translate-with-transition-creates-jumpy-animation-in-firefox

That said, something definitely changed because in versin 57 is was much more jittery.

Comment 5

[nrajbhan]

Starting with Firefox 58.0, we are noticing that animations with a similar setup are actually worse! When overflow:hidden and transform-style: preserve-3d are combined, the animations either jump directly from start to end or stutter along.

Here is an example where the child DIV is 150px tall but part of is hidden by nesting it inside a parent DIV that is 50px tall whose overflow is set to hidden.

<!DOCTYPE html>
<html>

<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <style type="text/css">    
    .child {
      position: absolute;
      background-color: green;
      left: 0px;
      top: 0px;
      height: 150px;
      width: 100px;
    }
    .parent {
      position: absolute;
      height: 50px;
      top: 50px;
      width: 100px;
      left: 100px;
      
      /* Comment the overflow: hidden style declaration OR the 
      transform-style: preserve-3d declaration for the animation
      to work on FireFox. */
      overflow: hidden;
      transform-style: preserve-3d;
      animation: slide-down 1s linear 0s 1 normal forwards;
    }
    @keyframes slide-down {
      0% {
        transform: translate3d(0px, 0px, 0px);
        animation-timing-function: linear;
      }
      100% {
        transform: translate3d(0px, 100px, 0px);
        animation-timing-function: linear;
      }
    }
  </style>
</head>

<body>
  <div class="parent">
    <div class="child"></div>
  </div>
</body>

</html>

Comment 6

[nrajbhan]

This animation worked fine in Firefox 57, and works fine in the current release versions of Chrome, Safari, IE, Edge, and Opera.

Comment 7

[nrajbhan]

I filed another bug https://bugzilla.mozilla.org/show_bug.cgi?id=1435902 since this is happening to many of our customers whose animations are no longer playing correctly when their web pages and ads are loaded into iframes.

Comment 8

[Alice0775 White]

Attachment: reporter's testcase(color modified)

Comment 9

[Alice0775 White]

This problem first appeared in Fx49(win10).

Comment 10

[Alice0775 White]

regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5613020111ba45dda63615dfa5a791f7ad1a8e4a&tochange=fe7766352e3eb84c9da204d866e8a25d814a09d8

Comment 11

[Hiroyuki Ikezoe (:hiro)]

Note that I've already fixed this locally and I thought I've also written an automation test, but I haven't written decent commit message yet. :)

Comment 12

[Hiroyuki Ikezoe (:hiro)]

I couldn't find the patch for this bug, because the patch I have was actually for bug 1428693.  And this is a dup of that. :)