@yangff1, Unable to reproduce the scenario, we tested the demo.html page in windows 10 with chrome latest stable version 53.0.2785.143 and with latest firefox browser and in both scenarios it's showing the empty red page.

Check the attached video and let us know whether it is right way to reproduce the issue?

@kkaluri I'm using jquery. `<script src="//cdn.bootcss.com/jquery/3.1.1/jquery.min.js"></script>` 
maybe you need start a local http server so chrome can load this script. (or download the script and use local path instead of `//cdn.bootcss.com/jquery/3.1.1/jquery.min.js`

And the whole things looks like this under 55.0.2879.0 (Official Build) canary (64-bit)

Deleted: 127.0.0.1_8111_demo.html - Google Chrome 10_3_2016 10_53_07 PM.mp4 9.5 MB

	127.0.0.1_8111_demo.html - Google Chrome 10_3_2016 10_53_07 PM.mp4 9.5 MB View Download

I can reproduce this bug on latest stable and Canary. The body position is incorrect once the animation starts which affects the animation. I have confirmed this on Mac and Linux too. Attached is a timeline recording.

Deleted: Animation-bug-20161003T142332 3.4 MB

Animation-bug-20161003T142332 3.4 MB View Download

Labeling with monthly update frequency on the assumption that this is not a regression

JSFiddle version of the test case to avoid the tedium of copy+paste+webserver:
https://jsfiddle.net/dvnr21pp/

Here is a simplified repro: http://jsbin.com/bakitu/3/edit?html,output

It is a combination of starting the animation and then causing the input to focus. This seems to cause the animation end style to get an incorrect value.

So I spend some more time today to dig into this deeper. As far as I can tell, this being caused by |LayoutObject::scrollRectToVisible| which is invoked as part of focus code path for html input (See HTMLInputElement::updateFocusAppearance). I verified this by returning early in that function and the issue is fixed indeed.


I am still not sure how that can cause this issue but just wanted to share what I know so far. 

Upon further investigation, this is not an issue with animation position calculation. Instead I found a bug in our scroll offset clamping that happens when a transform change is causing an overflow recalculation.

The original test page what animating transform (translateX) in a way that it was changing the containers layout overflow to change however we were failing to clamp the scroll offset correctly.

The input.focus() was essentially scrolling us to a position which would later become invalid thanks to the translation caused by the animation. However, we would not do the clamping.


This is not really about animation per-se but any translate would trigger this.
The simple test I wrote in my fix shows this: https://codereview.chromium.org/2524333003/


Here is my simplified repro based on the original report: 
http://jsbin.com/guzigilapu/edit?html,console,output

In general for best UX and visual effects, I suggest the input.focus()
to be called after animation ends. This avoids unnecessary visual jumps 
and ensures we focus the element at its final resting position.
 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/79f6f52c6732cd3082a9984329245b41c8c92a42

commit 79f6f52c6732cd3082a9984329245b41c8c92a42
Author: majidvp <majidvp@chromium.org>
Date: Mon Nov 28 17:38:52 2016

Clamp scroll offset after overflow reclacs that are not layout inducing

Changes in overflow content size and clip should trigger a re-clamping of
the scroll offset even if the change is not layout inducing (e.g., transform)

BUG= 652092 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://codereview.chromium.org/2524333003
Cr-Commit-Position: refs/heads/master@{#434679}

[add] https://crrev.com/79f6f52c6732cd3082a9984329245b41c8c92a42/third_party/WebKit/LayoutTests/fast/overflow/overflow-clamp-after-transform-related-content-size-change.html
[modify] https://crrev.com/79f6f52c6732cd3082a9984329245b41c8c92a42/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.cpp
[modify] https://crrev.com/79f6f52c6732cd3082a9984329245b41c8c92a42/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.h