Manual bisect:
Good build: 59.0.3057.0 
Bad build: 59.0.3059.0 

Note: Issue is not seen on Mac and Linux OS.

Deleted: dino_actual.mp4 655 KB

	dino_actual.mp4 655 KB View Download

Deleted: dino_expected.mp4 663 KB

	dino_expected.mp4 663 KB View Download

Using the per-revision bisect providing the bisect results,
Good build:59.0.3057.0 (Revision:460966).
Bad build:59.0.3059.0 (Revision:461269).

You are probably looking for a change made after 461083 (known good), but no later than 461084 (first known bad).

CHANGE-LOG URL:
---------------
https://chromium.googlesource.com/chromium/src/+log/826f594306b79439714faec487b06a9fd860c4a2..f2bd55f7d81eae9cd0736aaf68879ceb0309c92e

From the CL above, assigning the issue to the concern owner

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

Review-Url: https://codereview.chromium.org/2715243004
Note :Windows specific issue and Able to reproduce in latest Canary #59.0.3063.0
Adding Release Block-Stable for this issue.Please remove if not the case.

Could be related to my change, which modifies transparency calculation in blink. I'll have a look.

#2, can you explain how you narrowed down the revision range from 460966-461269 to 461083-461084? I'm just curious :)

We narrowed it down using "bisect-builds.py".

Thank you!

+chrishtr for question below.

I can confirm that my patch [1] is responsible for the regression. I was also able to repro the issue on chromeos (in a chrome binary built for target_os = "chromeos").

When the tab is reattached to the window, the canvas containing the dino isn't shown/drawn.

It seems this is due to additional calls to FrameView::setBaseBackgroundColor() that happen when the tab is reattached to the window. Putting aside the fact that those additional calls are unnecessary because the base background color didn't actually change (and we should fix that), I'd like to track down what is actually causing the canvas not to be drawn.

Within FrameView::setBaseBackgroundColor(), we call setNeedsDisplay() on the main GraphicsLayer [2]. Removing this call resolves the problem, so it seems that we're somehow painting over the canvas contents by invalidating the main GraphicsLayer. Do we need to do something else to repaint the canvas, too?

[1] https://codereview.chromium.org/2715243004/
[2] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/frame/FrameView.cpp?l=2352

Is the canvas in its own composited layer? Probably so.
I think this code in FrameView needs to change to call PaintLayerCompositor::setNeedsCompsitingUpdate(CompositingUpdateRebuildTree).
That should fix the problem.

Not sure the right label for this, but removing the network label, since it's a blink issue.

Thanks Chris, that seems to resolve the issue :)

https://codereview.chromium.org/2804983003/ is out to fix.

Debugged a bit further, it actually seems that the cause of the issue is that the canvas doesn't request a compositing update when the page becomes visible again (after being hidden during drag&drop of the tab).

The additional calls to SetBaseBackgroundColorOverride simply cause a situation in which no other compositing update is scheduled, but a repaint is.

The appropriate solution seems to add a setNeedsCompositingUpdate() call to HTMLCanvasElement::pageVisibilityChanged: https://codereview.chromium.org/2808493002

Just to update,
This issue is not seen on latest windows canary #59.0.3070.0

Deleted: 708445.mp4 769 KB

	708445.mp4 769 KB View Download

Yeah, it was fixed by https://codereview.chromium.org/2804983003.

However, while the problem isn't reproducible anymore, the root cause still exists - code review for fixing that is still pending: https://codereview.chromium.org/2808493002

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

commit 5047940999a9cf13e8635e61112fdaa7db885726
Author: eseckler <eseckler@chromium.org>
Date: Tue Apr 18 12:18:40 2017

[blink] Request compositing update when canvas hibernates/wakes up.

Not requesting the update can lead to the canvas not
being shown, as in the bug referenced below.

BUG= 708445 

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

[modify] https://crrev.com/5047940999a9cf13e8635e61112fdaa7db885726/third_party/WebKit/Source/core/html/HTMLCanvasElement.cpp
[modify] https://crrev.com/5047940999a9cf13e8635e61112fdaa7db885726/third_party/WebKit/Source/core/html/HTMLCanvasElement.h
[modify] https://crrev.com/5047940999a9cf13e8635e61112fdaa7db885726/third_party/WebKit/Source/modules/canvas2d/CanvasRenderingContext2DTest.cpp
[modify] https://crrev.com/5047940999a9cf13e8635e61112fdaa7db885726/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.cpp
[modify] https://crrev.com/5047940999a9cf13e8635e61112fdaa7db885726/third_party/WebKit/Source/platform/graphics/ImageBuffer.cpp
[modify] https://crrev.com/5047940999a9cf13e8635e61112fdaa7db885726/third_party/WebKit/Source/platform/graphics/ImageBuffer.h
[modify] https://crrev.com/5047940999a9cf13e8635e61112fdaa7db885726/third_party/WebKit/Source/platform/graphics/ImageBufferClient.h

[Auto-generated comment by a script] We noticed that this issue is targeted for M-59; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-59 label, otherwise remove Merge-TBD label. Thanks.

Your change meets the bar and is auto-approved for M59. Please go ahead and merge the CL to branch 3071 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

commit 0009f9a6c1416b2a23a33f69a86f5d21dccbf620
Author: Eric Seckler <eseckler@chromium.org>
Date: Wed Apr 19 12:41:34 2017

[blink] Request compositing update when canvas hibernates/wakes up.

Not requesting the update can lead to the canvas not
being shown, as in the bug referenced below.

BUG= 708445 

Review-Url: https://codereview.chromium.org/2808493002
Cr-Commit-Position: refs/heads/master@{#465206}
(cherry picked from commit 5047940999a9cf13e8635e61112fdaa7db885726)

Review-Url: https://codereview.chromium.org/2828693002 .
Cr-Commit-Position: refs/branch-heads/3071@{#47}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[modify] https://crrev.com/0009f9a6c1416b2a23a33f69a86f5d21dccbf620/third_party/WebKit/Source/core/html/HTMLCanvasElement.cpp
[modify] https://crrev.com/0009f9a6c1416b2a23a33f69a86f5d21dccbf620/third_party/WebKit/Source/core/html/HTMLCanvasElement.h
[modify] https://crrev.com/0009f9a6c1416b2a23a33f69a86f5d21dccbf620/third_party/WebKit/Source/modules/canvas2d/CanvasRenderingContext2DTest.cpp
[modify] https://crrev.com/0009f9a6c1416b2a23a33f69a86f5d21dccbf620/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.cpp
[modify] https://crrev.com/0009f9a6c1416b2a23a33f69a86f5d21dccbf620/third_party/WebKit/Source/platform/graphics/ImageBuffer.cpp
[modify] https://crrev.com/0009f9a6c1416b2a23a33f69a86f5d21dccbf620/third_party/WebKit/Source/platform/graphics/ImageBuffer.h
[modify] https://crrev.com/0009f9a6c1416b2a23a33f69a86f5d21dccbf620/third_party/WebKit/Source/platform/graphics/ImageBufferClient.h

Rechecked the issue on chrome version 59.0.3071.15 using Windows 10, fix is working as intended. Dino image is displayed after unpinning and merging chrome://dino page.

Adding TE-verified labels.

Thanks.!