Using the per-revision bisect providing the bisect results,
Good build: 59.0.3055.0 (Revision: 460255).
Bad build : 59.0.3056.0 (Revision: 460603).

You are probably looking for a change made after 460588 (known good), but no later than 460589 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/15364fec7ae7f0cca8bc46b691f1780ef251874b..0d7958ef3d03590b0063fe6d284763132e718b3f

@dgozman: 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.
Adding RB Label as this is a recent Regression.
Thank You.

Unable to reproduce this issue on Mac 10.12.4 and Windows 10 with chrome #59.0.3062.0
Attaching a screen-cast for reference.

dbote@ could you please confirm this?

Deleted: Issue 706711.mp4 1.3 MB

	Issue 706711.mp4 1.3 MB View Download

With respect to comment 2:

Issue is reproducible on 59.0.3062.0 using windows 10, please refer attached video.

Deleted: Actual_Issue.mp4 550 KB

	Actual_Issue.mp4 550 KB View Download

The problem is that link is a blob url (blob:chrome-devtools://devtools/3b90ba92-d37f-4d9e-85c0-5f0b8484e5d6), and I can open the file from downloads, but not this blob url in a new tab.

Not sure what is the proper solution - untriaging to get attention from downloads team.

Could some one from Downloads team please look into the issue and provide an update which would help us in further triaging.
Thanks in Advance.

Still able to reproduce the issue on Win 10.0 & 7 using latest chrome version 60.0.3074.0.

qinmin@ Could you please look into this issue.

Thanks!

For M57, Chrome uses data uri for the fullscreen capture, but with the latest versions, we  switch to blob uri, and that causes the issue. Any idea why blob is prefered over data uri?

IIRC, blob supports larger size, while data uri failed for huge canvas.

I am seeing the following log:
[5292:5292:0424/124531.291536:ERROR:CONSOLE(0)] "Not allowed to load local resource: blob:chrome-devtools://devtools/70f9af77-a3ce-4044-b4ee-a301f4abaab5", source: chrome://downloads/ (0)

So the blob url was unable to load due to security issues. This doesn't look like a download issue, it is related to FrameLoader and security. Assigning to japhet@ to take a look.

japhet@, would you please triage this?

Issue is still reproducible using latest Chrome #60.0.3093.0 on Win 10 and Mac 10.12.4.

@japhet: Is there any update on this issue?

Thanks,

mkwst is probably better able to evaluate whether there's any way we can relax the security rules here.

Feel free to reassign to me if I'm wrong :)

Reminder that M59 Stable is launch is coming soon (less than 2 weeks)! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

Gentle ping to check if we have any update on the fix, As stated in comment#14 we are just 1 week away from M59 stable launch.

Hi. Sorry, I misread the thread, and thought japhet@ was handling this. :(

After playing around with this a little locally on a ToT build, the screenshot works just fine, the PNG file downloaded to disk is exactly what I'd expect it to be, clicking the downloaded image from the downloads page works, etc. The broken bit is opening the downloaded image in a new tab from the downloads page. I don't see that as a P1 stable-blocker given the relative usage of both the downloads page and open in a new tab, but I'll leave that determination up to the release managers.

We block the navigation to `blob:chrome-devtools://...` because `chrome-devtools:` is registered as a display-isolated scheme (https://cs.chromium.org/chromium/src/content/renderer/render_thread_impl.cc?rcl=e160c7fb49196d45a38bea32e8eb7e74f22922fe&l=1271), so we prevent navigation to those URLs. I suppose we could relax that restrictions for `chrome:` URLs in particular (as opposed to `https:` URLs, for example), but that would require a new registry and some careful thought about how we structured things. +creis@ who might have opinions. I don't think it's something we'd want to build in a hurry for a merge back to M59.

Since this is related to security policy, removing myself from owner

I agree with mkwst@ in comment 16 that this should not be a blocker, given that the user can open the actual saved file. Further agree that any security policy relaxation cannot be made quickly and backported.

Removing ReleaseBlock-Stable based on the above.

Comment 16: I don't think we want to relax the display-isolated scheme restriction for chrome-devtools:// from chrome:// URLs.  This doesn't seem like a strong enough case to justify the extra complexity and potential attack surface by mixing those schemes.

I also feel like that would only be a partial fix anyway-- as soon as DevTools closes, the underlying blob URL goes away and you won't be able to download it again.  In fact, the same is true for *any* blob URL downloaded from a normal web page.  chrome://downloads will show the blob URL, but that link will stop working once the user navigates away from the page it was created on.

It's true we could try to find ways to make the blob URL work for DevTools as long as DevTools is still open (e.g., Nick only half-seriously suggested creating it in a sandboxed iframe with a unique origin), but I'm not sure that's worthwhile given it will stop working anyway when DevTools closes.

Maybe this is more of a UX question about how blob URLs should behave on chrome://downloads.  Should we even make them links?  I could see not doing that for blob URLs, since they're likely to stop working before long.  (Conversely, I could also see marking this bug WontFix, since it's such a small corner case.)

Back to qinmin@ to decide how chrome://downloads should behave.