====================================

Good Build:

50.0.2633.0    Base Position: 371964


Bad Build:

50.0.2634.0    Base Position: 372490

=====================================

Able to repro this issue on Windows 7 & Ubuntu Trusty (14.04) for the Google Chrome Stable Version - 50.0.2661.102

This is a regression issue broken in M50, below mentioned is the bisect info:

CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/b908e01c1385dfe034c8a2a1f223ab1d4355ae81..030a20f905684130a995def26ce72d4783c846bd

Suspecting Commit: 510e13d1579b8fb895673358ac1a6594fbcadfe3

Review URL: https://codereview.chromium.org/1616183002

@wkorman: Could you please look into the issue, and if it has nothing to do with your changes and if possible please do assign it to the concerned owner.

Thank you.

Confirmed that commit 510e13d1579b8fb895673358ac1a6594fbcadfe3 is where the regression started.
Unable to cleanly revert, this is affecting stable, please investigate.

I'm looking at this. Commenting out lines 770 - 773 in PaintLayerCompositor, added in http://crrev.com/1616183002, fixes the provided test case.

Note from ajuma@ on hypothesis: ...[possible that] animation framework needs to be told that the composited layer is going away, so it knows to either takeover the animation and/or try to add it back when the composited layer comes back. Element::detach calls restartAnimationOnCompositor to handle the case of layers going away because of display:none, maybe something similar is needed for visibility:hidden iframes.

A couple of notes from investigation:

The elements are never detached when the iframe is hidden. A side effect of http://crrev.com/1616183002 is that the composited layer mapping associated with the hidden iframe is removed, whereas previously they stayed around even though they weren't visible.

I also see PaintLayerCompositor::{attach,detach}AnimationTimeline. Prior to my change, after initial load, neither were called when the iframe was then hidden/shown. With my change, detachAnimationTimeline is still never called, but attachAnimationTimeline is now called when we re-allocate the CLM. In general I would have thought we'd want CLM existence to be paired with attach/detachAnimationTimeline calls.

I need to learn more about how animation operates, but it may be that it's trying to paint to a graphics layer that no longer exists, or that we need to fix the pairing of the attach/detachAnimationTimeline calls, or something else.

Test case (just saved off from original bug report) is attached, open visibility.html.

Deleted: visibility.tar.gz 1013 bytes

visibility.tar.gz 1013 bytes Download

Hacking a call to:

toElement(layer->layoutObject()->node())->elementAnimations()->restartAnimationOnCompositor()

when we allocate a new composited layer mapping such as here:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/layout/compositing/PaintLayerCompositor.cpp&q=paintlayercompositor&sq=package:chromium&type=cs&l=484

fixes things, but often requires a mouse movement before animation begins painting again for some reason.

Removing Blink>Animation label since the bug is in the code which uses animations. The animation team members are in CC list.

Sent http://crrev.com/2010963003 for discussion.

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

commit 851bbadbc2348dcf79851c9be1b766e4ce00a2ab
Author: wkorman <wkorman@chromium.org>
Date: Wed Jun 01 00:57:38 2016

Restart any animations when we allocate a composited layer.

As part of this, fix FrameView to note a compositing update is needed
when it is shown/hidden since it could gain/lose its composited layer
and, if shown/gained, then we want to immediately restart any
animations.

BUG= 612436 

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

[modify] https://crrev.com/851bbadbc2348dcf79851c9be1b766e4ce00a2ab/third_party/WebKit/Source/core/frame/FrameView.cpp
[modify] https://crrev.com/851bbadbc2348dcf79851c9be1b766e4ce00a2ab/third_party/WebKit/Source/core/layout/compositing/PaintLayerCompositor.cpp