To be exact, "Does this work in other browsers? Yes" -- might better be "Not applicable".

Able to reproduce the issue on Windows 10, mac 10.13.3 and Ubuntu 14.04 using chrome reported version #65.0.3325.181 and latest canary #67.0.3386.0.

Bisect Information:
=====================
Good build: 65.0.3309.0
Bad Build : 65.0.3310.0

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/cbce1149c9ae08297b816effbf456c02f97df8db..f2d2fe87028de36a489f7db3f5fb28da2e9d9b2b

From the above change log suspecting below change
Change-Id: I508d7abe1cba9b75d65132b0688984cdebfc6fd4
Reviewed-on: https://chromium-review.googlesource.com/758236

jochen@ - 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.
Note: Adding stable blocker for M-65 as it seems to be a recent regression. Please feel free to remove the same if not appropriate.
Thanks...!!

This almost certainly is a duplicate of 807639, except that https://chromiumdash.appspot.com/commit/7b43f737ce7b421ca8717f604db045e7fbb4e7b3 was supposed to work around the breakage jochen's change caused, and that CL shipped in 65.0.3325.53, while apparently here it is still reproducable in later M65 versions...

I'm working on some CLs that should fix all these revoke+resolution ordering issues once and for all, but that's probably not going to ship till M68 (or maybe M67, but likely won't make it for that branch).

Hmm, so my previous work-around "fixed" the issues caused by IPC ordering (and the fact that pre-jochen's CL both download and blob URL IPCs arrived on the IO thread and thus were properly ordered, while after his CL download IPCs arrive on the UI thread instead).

But I failed to address the other half of the problem: pre-jochen's CL,  RenderFrameMessageFilter::DownloadUrl immediately resolved the blob URL as soon as it got the IPC, but the navigation code doesn't do anything like that until much later, once it actually starts the download. So I'm guessing somehow extensions do more async work in between getting the navigation IPC and actually doing the fetch, and that is somehow causing this to still fail for extensions.

Now as I said I am working on rewriting a bunch of this stuff (and resolve blob URLs in blink before any IPCs are send), to make sure we'll never run into any of these race conditions again. But not sure when I'll be able to get that all landed, as there are still some missing pieces (in particular currently it depends on the network service being enabled, although it should be possible to make it work even without that).

Sorry about the mess. I'm working on a cl to route blob urls back through the old codepath

We're not planning any more M65 releases. Pls target fix for M66.

This is even a problem without calling URL.revokeObjectURL().

For example, see the attached repro extension.

If you try to click the "Download File" anchor that appears (using the Blob object URL), it does not work. This used to work.

        const req = new XMLHttpRequest();
        req.open('GET', 'https://i.imgur.com/aI5UoGb.png', true);
        req.responseType = 'arraybuffer';
        req.onload = function (evt) {
            if (!req.response) {
                console.log('error');
                return;
            }
    
            console.log('success');
            const blob = new Blob([req.response], null);
            const a = window.document.createElement('a');
            a.href = window.URL.createObjectURL(blob);
            a.download = 'google_logo.png';
            a.innerText = 'Download File';
            window.document.body.appendChild(a);
        };
        req.send(null);

Deleted: download-test.zip 3.0 KB

download-test.zip 3.0 KB Download

Reminder: Please note that M66 Stable is only 7 days away. This bug has been marked as ReleaseBlock Stable for M66. So please take a look and appropriately address this bug. 

that should be fixed in 66

[Auto-generated comment by a script] We noticed that this issue is targeted for M-66; 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-66 label, otherwise remove Merge-TBD label. Thanks.

Able to reproduce the issue on Mac 10.13.3 using chrome build without fix.

Verified the fix on Mac 10.13.3, Win-10 and Ubuntu 17.10 using Chrome stable version #67.0.3396.99 as per the comment #0.
Attaching screen cast for reference.
Observed that the download operation worked well while set to 0 (no-delay).
Hence, the fix is working as expected. 
Adding the verified labels.

Thanks...!!

Deleted: 827932.mp4 473 KB

	827932.mp4 473 KB View Download