Good Build: 54.0.2807.o
Bad Build: 54.0.2809.0

Narrow Bisect: 
https://chromium.googlesource.com/chromium/src/+log/f6ad04c6319183cc6b04186f3a801a1241c8fbbc..84f2e1094a5c68772871d4a15e4609d2a1ede90e?pretty=fuller&n=100

Suspecting: r407616

@yoav: Please help me to reassign this issue,if your change is not cause for it.

Deleted: Actual_Video.mp4 694 KB

	Actual_Video.mp4 694 KB View Download

Deleted: Expected_Video.mp4 828 KB

	Expected_Video.mp4 828 KB View Download

Adding RB Label as this is a recent Regression. Please remove if not required.
Thank You.

The issue is indeed related to my change.

However, I believe that the real issue here is that the screenshot functionality somehow relies on data URIs sync loading, in a way that is not tested.

So I suggest an immediate revert of my change, which will be followed by a fix to the real underlying issue, after which we'd be able to re-land async loading of data URIs.

Revert sent to the CQ.

pfeldman@ - do you know who could look into the screen capturing issue?

@yoav: devtools paints the image on the canvas and then does

var link = createElement("a");
link.download = fileName + ".png";
link.href = canvas.toDataURL("image/png");
link.click();

I'm not sure where we rely upon async loading of URIs since we don't load URIs in this case...

pfeldman@- interesting. So you suspect link downloading of a data URI is what actually broke with that patch? So you know if we have tests for that? (or know who would?)

@yoav: if it is bisected to your patch, you are our best bet.

Adding Downloads component, and rdsmith@ as proxy for asanka@ (who is OOO).

I don't know how <a download>s work, but I bet this is turning something deterministic into a race between the image loading and the download initiating.

Hmm actually now I'm not so sure. From the video it seems like the problem might be navigating the main frame to a data url? It might make sense to diff two <a download>s with and without the patch.

Nevermind. I have confirmed that the data url that is saved is corrupt somehow. Saving it and opening it in another application / chrome M52 also shows an empty image.

Yoav@, what is the status of the revert?

Hm. I'm having trouble reproducing this on any other canvas element using the technique illustrated in #5. All data urls save and display fine.

pfeldman@, can you give a reference to where in the code devtools does this saving?

This is working fine on the latest canary 54.0.2827.0 using Mac 10.11.6,Win 7 and Ubuntu 14.04.
rkote@ : Could you please review the attached screen cast and let us know if its fine.
Removed the Blocker label as its working fine on latest canary.

Deleted: 632277_Aug_12.mp4 1.1 MB

	632277_Aug_12.mp4 1.1 MB View Download

With respect to comment 12:

Issue is seems to be fixed in latest build 54.0.2827.0 

Thank you.

Yoav reverted the patch, so this issue is fixed.

Turns out the devtools dependency on sync loading wasn't in the link's download but when loading the image before painting it on the canvas... CL up for review at https://codereview.chromium.org/2592113003/