You are probably looking for a change made after 534833 (known good), but no later than 534844 (first known bad).
CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/d83eee7eb1d2636c7fcf8dc2fb6eac57a80daa9d..825484cf268844e5bdf66ccdf84e5df2a0e59a1b

Suspect from CL: r534843 ?
                   
Below is the roller group:
https://webrtc.googlesource.com/src.git/+log/29f14322d13e..dffead8835d1 

Suspect from roller: r21920 ?
(Got Auto-Roll group in bisect CL,Hence assigning it to the @shampson)

@shampson: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Adding release blocker label for this issue.Please reduce priority or remove if not the case.

FYI: Same issue on Archlinux OS with Chromium Version 64.0.3282.167 (Build de développement) (64 bits)

Update:

Above issue is still reproducible on latest canary 67.0.3375.0 (Official Build) and on latest dev 67.0.3371.0 (Official Build) in Win(7,8,8.1,10) OS

Note: As @shampson is not available assigning the bug to reviewer.

@sprang: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.
 
Please refer attached screencast

Deleted: Actual_Canary_Screenshot.mp4 1.2 MB

	Actual_Canary_Screenshot.mp4 1.2 MB View Download

Deleted: Actual_Dev_Screenshot.mp4 1.2 MB

	Actual_Dev_Screenshot.mp4 1.2 MB View Download

No, these changes only affect what resolutions we transmit on the network during a WebRTC video call, which sounds completely unrelated to this issue.

Could some one from devtools team,please take a look.

With response to comment #5:

Re-bisected again using per-revision script and below is the bisect info.

You are probably looking for a change made after 534837 (known good), but no later than 534838 (first known bad).
CHANGELOG URL:
The script might not always return single CL as suspect as some perf builds might get missing due to failure.
https://chromium.googlesource.com/chromium/src/+log/45236331103f6989087e74313c572ae5e84ee9c5..e544a1ed8f62f4416060033ee0ff2ca0050af896

Suspect: https://chromium.googlesource.com/chromium/src/+/e544a1ed8f62f4416060033ee0ff2ca0050af896

@yiyix: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

i can't reproduce it any more. Could we do another bisect and understand which cl has fixed it? Thank you.

I attached a video to describe what i see.

Deleted: temp.mkv 3.8 MB

temp.mkv 3.8 MB Download

could you verify is resolved on the ToT? Thank you very much.

With respect comment 11:

Above issue is fixed on ToT and working as intended. kindly refer attached screenshot for the same.

Thank you.

Deleted: Actual_Fix.mp4 693 KB

	Actual_Fix.mp4 693 KB View Download

What is the next step for me? Do I need to do the bisect to find the cl that fixes the issue and merge it to M66?

If that is the case, could you teach me how to use the tool to do bisect?

Thank you.

I tried to reproduce this problem on a Windows 10 64bit machine with version 66.0.3342.0 (Revision:534887), and I cannot reproduce it. Could anyone confirm that this bug still exists in the M66 beta version? Thanks.

With response to comment# 13 & 14

Rechecked again and issue is specific to different screen resolution on Windows machine as mentioned below:

--Case 1: Screen Resolution 1366*768 for Windows

Above issue is still reproducible on Win(7,8,8.1,10) for latest canary 67.0.3383.0 , latest beta 66.0.3359.66 & version 66.0.3342.0 
Please refer attached screencast for Windows 10 

--Case 2: Screen Resolution 1280*1024 for Windows

Above issue is not reproducible on Win(7,8,8.1,10) latest canary 67.0.3383.0 , latest beta 66.0.3359.66 & version 66.0.3342.0 
Please refer attached screencast for Win 10 resolution  & Win 7

As the issue is not fixed in case 1 can't provide reverse bisect(i.e revision where it's fixed)


Thank You!

Deleted: Actual_Win10.mp4 1.1 MB

	Actual_Win10.mp4 1.1 MB View Download

Deleted: Actual_Win10_resolution.mp4 1.5 MB

	Actual_Win10_resolution.mp4 1.5 MB View Download

Deleted: Actual_Win7.mp4 1.4 MB

	Actual_Win7.mp4 1.4 MB View Download

vkupte@etouch.net: Do you experience this problem every time you try to "capture the full size screenshot"? I am trying to understand if it's a race condition or it's a logic bug. 

I have tried your reproduction steps for more than 20 times on 3 windows machine that we have at office, and I still couldn't reproduce it. I am also wondering if it's possible that you are on some kind of finch experiment groups and it's broken due to some finch experiment. dbote@etouch.net: if you don't mind, could you verify that if you can reproduce it with m66? From the replies, it looks like @vkupte is only person can reproduce the bug. 

Since I cannot reproduce it and the problem exists for a specific resolution, I will remove the stable-release blocker label. 

With respect to comment 16:

Screen Resolution 1280*1024 for Windows:
Above issue is not reproducible on Win(7,8,8.1,10) using latest beta 66.0.3359.66 

Screen Resolution 1366*768 for Windows:
Above issue is still reproducible on Win(7,8,8.1,10) using latest beta 66.0.3359.66

Note: Above issue is specific to 1366*768 resolution on windows.


Please refer attached screencast for resolution.

Thank you.

Deleted: Actual_resolution.mp4 1.4 MB

	Actual_resolution.mp4 1.4 MB View Download

Deleted: Actual_Win10.resolution.mp4 1.0 MB

	Actual_Win10.resolution.mp4 1.0 MB View Download