Unable to check the issue on reported chrome version 63.0.3239.84 using Windows 10 with the below mentioned steps. 

1. Launched Chrome Using Windows 10
2. Connected Dual monitor cable to the cpu of Win 10 OS

As the second monitor fails to respond/Going to sleep mode we coudn't check. Tried by having Win7 as Main system too, same issue is seen.

@Inhouse: Could some one from TE-HYD team have a look into this issue. Hence adding label TE-NeedsTriageFromHYD.

Thanks!

Sorry for confuse this post. 63.0.3239.84 is not happen this bug. Exactly start from 63.0.3239.108 to black filled top area of tab.

Able to reproduce the issue on Windows 10 with chrome Stable #63.0.3239.108 , Beta #64.0.3282.39, Dev #	65.0.3298.3 & Canary #65.0.3304.0
Issue broken between M64 & M65

Bisect Info:
===========
Good build :  64.0.3282.0,  Revision Range - 520840
Bad build  :  65.0.3285.0,  Revision Range - 521571

Manual Change Log between Good & Bad builds
======================================
https://chromium.googlesource.com/chromium/src/+log/64.0.3282.0..65.0.3285.0?pretty=fuller&n=10000


The suspecting Change Log is :
-----------
https://chromium.googlesource.com/chromium/src/+/a9634625b03962f7fdb714153a6fb8564da4084b


Note:
1. Unable to run per-revision bisect script, since it is breaking on Windows 10 machine.
2. Not able to repro on Ubuntu 14.04 & Mac 10.12.6

ccameron@- Could you please look into this issue, if it's related to your change?  if not could you please help us to reassign this issue to the right owner.

Deleted: 796828-Good.mp4 1.6 MB

	796828-Good.mp4 1.6 MB View Download

Deleted: 796828-Bad.mp4 827 KB

	796828-Bad.mp4 827 KB View Download

Deleted: 796828-Stable.mp4 1.2 MB

	796828-Stable.mp4 1.2 MB View Download

Deleted: 796828-Beta.mp4 753 KB

	796828-Beta.mp4 753 KB View Download

Deleted: 796828-Dev.mp4 1.4 MB

	796828-Dev.mp4 1.4 MB View Download

Deleted: 796828-Canary.mp4 734 KB

	796828-Canary.mp4 734 KB View Download

I can confirm that I also see the problem with Chrome 63.0.3239.108 (Official Build)(64-bit) on Windows 10 1709 (build 16299.125).

The owner of this issue is ooo , hence adding the reviewer of the file as per comment #5 for more updates on this issue.

Thanks!

This issue is marked as RB-Stable for M64, could any one let us know is there any latest update available on this issue?

Thanks!

I will take a look at this next week when I have access to my Windows machine.

In the mean time, please navigate to about:gpu in Canary on an affected machine print the result as a PDF, and attach that.

As per comment #9, attaching the GPU of affected windows 10 machine on chrome  canary #65.0.3316.0

Deleted: 796828-gpu.pdf 147 KB

796828-gpu.pdf 147 KB Download

ccameron@,
Attached GPU details as per C#9,Could you please take a look as it is marked as stable blocker.

Thanks..!

We're not planning any further M63 releases. 

abdulsyed@ to evaluate for M64.

Thanks, I'll try to reproduce this

 Issue 802148  has been merged into this issue.

 Issue 801833  has been merged into this issue.

Hmm, seeing lots of dupes of this, but still can't repro :/

windows 10 machine on chrome canary 65.0.3325.0

Deleted: win10-gpu.pdf 2.3 MB

win10-gpu.pdf 2.3 MB Download

I think that this is a damage tracking bug.

A side-effect of changing the color space on the ui::Compositor is that we call cc::Layer::SetNeedsDisplay on every layer in the tree. That side-effect is making the layers not appear black.

Digging in a bit more here...

Forcing a re-display of the full window every frame results in lots of black flickering ...
  current_frame()->root_damage_rect = gfx::Rect(device_viewport_size);

We call this whenever reshape is called, which happens for output color space changes, among many other things...

Merging into issue 804430...

Actually, I'll do a separate fix for this -- that bug is tricky.

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

commit 4f96f1f0fbf78ea9b6d6ccb0e9f6ec995497a0c3
Author: Christopher Cameron <ccameron@chromium.org>
Date: Wed Jan 24 07:19:34 2018

Work around black flashing in ui::Compositor

The root cause for this bug is crbug.com/804430, where we optimize away
required quads because we aren't aware of a reshape.

The fix for that bug will be subtle, and this needs merges, so just lie
and say that we changed the UI color space even if it's still always
just sRGB.

Bug:  796828 
Change-Id: I23929eb92a780020f67f003985823b01a77901e3
Reviewed-on: https://chromium-review.googlesource.com/879395
Reviewed-by: weiliangc <weiliangc@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#531470}
[modify] https://crrev.com/4f96f1f0fbf78ea9b6d6ccb0e9f6ec995497a0c3/ui/compositor/compositor.cc

Verified the fix on Windows10 using Chrome version #66.0.3331.0 as per the comment #0.
Attaching screen cast for reference.
Observed that the movement of window from one monitor to other is clear with out any black-out
Hence, the fix is working as expected. 
Adding the verified labels.

Thanks...!!

Deleted: 796828.mp4 8.0 MB

	796828.mp4 8.0 MB View Download

Adding 65 merge request

Your change meets the bar and is auto-approved for M65. Please go ahead and merge the CL to branch 3325 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

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

Pls merge your change to M65 branch 3325 ASAP so we can pick it up for next M65 dev release. Thank you.

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

commit 49614d7b9e7d8dc3b0a4c4b8c576a3e7753ff859
Author: Christopher Cameron <ccameron@chromium.org>
Date: Mon Jan 29 18:52:48 2018

Work around black flashing in ui::Compositor

The root cause for this bug is crbug.com/804430, where we optimize away
required quads because we aren't aware of a reshape.

The fix for that bug will be subtle, and this needs merges, so just lie
and say that we changed the UI color space even if it's still always
just sRGB.

TBR=ccameron@chromium.org

(cherry picked from commit 4f96f1f0fbf78ea9b6d6ccb0e9f6ec995497a0c3)

Bug:  796828 
Change-Id: I23929eb92a780020f67f003985823b01a77901e3
Reviewed-on: https://chromium-review.googlesource.com/879395
Reviewed-by: weiliangc <weiliangc@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#531470}
Reviewed-on: https://chromium-review.googlesource.com/891683
Reviewed-by: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#147}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/49614d7b9e7d8dc3b0a4c4b8c576a3e7753ff859/ui/compositor/compositor.cc

Verified the fix on Windows 10 using Chrome version #65.0.3325.31 as per the comment #0.
Attaching screen cast for reference.
Observed that the movement of window from one monitor to other is clear with out any black-out
Hence, the fix is working as expected. 
Adding the verified labels.

Thanks...!!

Deleted: 796828 CL Verification.mp4 5.6 MB

	796828 CL Verification.mp4 5.6 MB View Download