chrome.downloads.download does not work with blob URLs with network service enabled [41439098]

Fixed

Bug

Needs-Triage-M72

Triaged-ET

Chromium-Regression

Status Update

No update yet.

Description

gt...@gmail.com

created issue #1

Feb 4, 2019 04:05PM

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.81 Safari/537.36

Steps to reproduce the problem:
1. Open up 'Extensions'
2. Turn on the 'Developer mode'
3. 'Inspect views' for any random extension to open up the extension's console
4. Run this line of javascript:
console.log(URL.createObjectURL( new Blob(['test'], {type: 'text/plain'}) ));
5. Copy the printed URL which will be in the format of: blob:chrome-extension://chjpchfchpknieidncedaigaednecjlg/5d115834-4cc1-46d9-9e27-78b96be6b270
6. Paste the URL in a new tab and request the URL
7. You'll see the browser ignores the request. Nothing happens.

What is the expected behavior?
The browser is going to request this blob from its local blob URL store. You'll see the text 'test' returned as this is the content we set for the blob.

What went wrong?
As of Chromium version 72.0.3626.81 the browser does not allow to request anything from the blob URL store when this is done from an Chrome extension.

You can perform the same steps in a random browser tab and you'll see the blob URL store does work in Chrome version 72. This shows the issue is specific for when doing this from an extension.

One thing I noticed when testing this is in an ancient Chrome version is there the console prints the blob URL as a URL safe string. That means, chrome-extension:// is printed as chrome-extension%3A//. In Chrome 72 I tried if this was the actual issue, but its not, it still fails. Requesting the blob URL in this way does finally print some error in the console though: Not allowed to load local resource: blob:chrome-extension%3A//chjpchfchpknieidncedaigaednecjlg/5d115834-4cc1-46d9-9e27-78b96be6b270

Thats why I assume somehow requesting the blob URL store from an extension is somehow made impossible/forbidden.

WebStore page:

https://chrome.google.com/webstore/detail/saml-to-aws-sts-keys-conv/ekniobabpcnfjgfbphhcolcinmnbehde

Did this work before? Yes 71

Chrome version: 72.0.3626.81 Channel: stable
OS Version: OS X 10.12.6
Flash Version:

Comments

su...@chromium.org <su...@chromium.org> #2Feb 4, 2019 05:43PM

[Empty comment from Monorail migration]

ja...@chromium.org <ja...@chromium.org> #3Feb 4, 2019 06:26PM

FYI I tried this with network service disabled (to make sure it's not a NS bug) and it failed.

me...@chromium.org <me...@chromium.org> #4Feb 4, 2019 06:48PM

It seems to work if I for example window.open from within the extension, but does indeed appear to be broken when navigating to the blob URL by pasting it in the omnibox.

[Monorail components: Blink>Storage>FileAPI]

me...@chromium.org <me...@chromium.org> #5Feb 4, 2019 06:59PM

Hmm, actually not sure the repro steps are correct, if this is a new bug in M72. At least for me the repro steps as given behave the same going as far back as M63 (just trying some random revisions). Copy-pasting a chrome-extension blob URL into the omnibox doesn't work, but loading it from the extension using window.open works correctly.

So what exactly is it that used to work correctly but doesn't work anymore?

gt...@gmail.com <gt...@gmail.com> #6Feb 4, 2019 07:04PM

Fair enough. What I'm using in the extension is these two lines of code:

var doc = URL.createObjectURL( new Blob([docContent], {type: 'application/octet-binary'}) );

chrome.downloads.download({ url: doc, filename: FileName, conflictAction: 'overwrite', saveAs: false });

As from version 72 this results in a failed download (Failed - network error)

So I agree, hypothetically the issue could be something else than the blob URL store. It could also be changed behaviour of the chrome.download API.

gt...@gmail.com <gt...@gmail.com> #7Feb 4, 2019 07:07PM

The above code comes directly from the extension, but you could use these two lines to test the behaviour:

var blob = URL.createObjectURL( new Blob(['test'], {type: 'text/plain'}) );

chrome.downloads.download({ url: blob, filename: 'test.txt', conflictAction: 'overwrite', saveAs: false });

me...@chromium.org <me...@chromium.org> #8Feb 4, 2019 07:26PM

Ah yes, that does appear to be a network service regression. It works with network service disabled, but fails when network service is enabled

In a debug build it crashes with [188569:188569:0204/112216.188029:FATAL:download_manager_impl.cc(1234)] Check failed: params->url().SchemeIsBlob() == bool{blob_url_loader_factory} (1 vs. 0)

I should be able to fix this fairly easily

gt...@gmail.com <gt...@gmail.com> #9Feb 4, 2019 07:29PM

Awesome. Many thanks!

me...@chromium.org <me...@chromium.org> #10Feb 4, 2019 07:35PM

Accepted by me...@chromium.org.

[Empty comment from Monorail migration]

me...@chromium.org <me...@chromium.org> #11Feb 4, 2019 07:40PM

[Empty comment from Monorail migration]

ja...@chromium.org <ja...@chromium.org> #12Feb 4, 2019 08:05PM

Thanks for reducing to a repro that fails with NS only.

Do we know how important this is for stable rollout? e.g. is this a common use case or an edge case where we can punt the fix to 73?

[Monorail components: Internals>Services>Network]

ja...@chromium.org <ja...@chromium.org> #13Feb 4, 2019 08:10PM

btw I saw the fix from Marijn (thanks for the quick fix!) should be risk-free, so maybe we should merge it to 72 before the respin. It's only in the network service path, and it's similar to a recent fix in a similar path that's been safe:

https://chromium.googlesource.com/chromium/src/+/3fea4c4ad6c0d3d7b3580ad47c627332f7922b86

gt...@gmail.com <gt...@gmail.com> #14Feb 4, 2019 09:47PM

I can only speak for what I know. This extension is used by over 2400 users. Most likely on a day to day basis, but not entirely sure about that.

Obviously I don't know the bigger picture, so I'm not sure if this qualifies as a common use case or an edge case. Besides me there could of course also be other extensions using the chrome.download API in a similar way.

bu...@chops-service-accounts.iam.gserviceaccount.com <bu...@chops-service-accounts.iam.gserviceaccount.com> #15Feb 4, 2019 10:13PM

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src.git/+/f5534db9782f9bcb83e062e8bb6d341a458070a8

commit f5534db9782f9bcb83e062e8bb6d341a458070a8
Author: Marijn Kruisselbrink <mek@chromium.org>
Date: Mon Feb 04 22:13:14 2019

Fix blob URLs in the chrome.downloads API with network service enabled.

Long term the chrome.downloads implementation should probably resolve
blob URLs in the renderer process before sending the IPC to the browser,
as that is the only way to guarantee that the blob URL can resolve
correctly, but this fix should at least for most cases.

Bug: 928307
Change-Id: I85b29c91ff1d89451811b30ea7a9f8d22f853ea2
Reviewed-on:

https://chromium-review.googlesource.com/c/1452778
Reviewed-by: Min Qin <qinmin@chromium.org>
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#628893}
[modify]

https://crrev.com/f5534db9782f9bcb83e062e8bb6d341a458070a8/content/browser/download/download_manager_impl.cc

me...@chromium.org <me...@chromium.org> #16Feb 4, 2019 10:20PM

Per

https://crbug.com/chromium/928307#c12, requesting merge to 72 and 73

sh...@chromium.org <sh...@chromium.org> #17Feb 4, 2019 10:22PM

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: govind@(Android), kariahda@(iOS), djmm@(ChromeOS), abdulsyed@(Desktop)

For more details visit

https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

vi...@chromium.org <vi...@chromium.org> #18Feb 5, 2019 06:10AM

As per comment# 14, the fix is already landed, hence removing Needs-Bisect label.

Thanks!

su...@chromium.org <su...@chromium.org> #19Feb 5, 2019 12:34PM

Able to reproduce this issue on Windows 10, Mac OS 10.13.6 and Ubuntu 14.04 on the reported version 72.0.3626.81 and the issue is fixed on the latest M-74 build 74.0.3694.0 as per

https://crbug.com/chromium/928307#c6.

1. Launched Chrome and enabled #network-service flag.
2. Navigated to chrome://extensions and turned on the 'Developer mode'.
3. Added the extension

https://chrome.google.com/webstore/detail/saml-to-aws-sts-keys-conv/ekniobabpcnfjgfbphhcolcinmnbehde.
4. Navigated to chrome://extensions and clicked on background page.
5. executed the code mentioned in

https://crbug.com/chromium/928307#c6 in console and could observe that the test file is downloaded.
Attached is the screen cast for reference.

Hence adding TE verified labels as the fix is working as intended.

Thanks..

928307-M74.mp4

2.9 MB

Download

ab...@google.com <ab...@google.com> #20Feb 5, 2019 05:48PM

mek@ - how safe is this merge? What are the chances of this introducing new regressions? I realize this is affecting only in the network service path (which is behind a flag).

me...@chromium.org <me...@chromium.org> #21Feb 5, 2019 05:50PM

This should be perfectly safe. As mentioned it only effects the network service path, and it only does anything in cases that were broken before. So this really shouldn't be able to introduce any new regressions.

ab...@google.com <ab...@google.com> #22Feb 5, 2019 08:27PM

Approving merge for M72. Branch:3626
Approving merge for M73. Branch:3683

cr...@appspot.gserviceaccount.com <cr...@appspot.gserviceaccount.com> #23Feb 5, 2019 08:46PM

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src.git/+/2d7e342fe59600e1f8d1d6ca8e4591847d5fc3b3

Commit: 2d7e342fe59600e1f8d1d6ca8e4591847d5fc3b3
Author: mek@chromium.org
Commiter: mek@chromium.org
Date: 2019-02-05 20:44:47 +0000 UTC

Fix blob URLs in the chrome.downloads API with network service enabled.

Long term the chrome.downloads implementation should probably resolve
blob URLs in the renderer process before sending the IPC to the browser,
as that is the only way to guarantee that the blob URL can resolve
correctly, but this fix should at least for most cases.

TBR=mek@chromium.org

(cherry picked from commit f5534db9782f9bcb83e062e8bb6d341a458070a8)

Bug: 928307
Change-Id: I85b29c91ff1d89451811b30ea7a9f8d22f853ea2
Reviewed-on:

https://chromium-review.googlesource.com/c/1452778
Reviewed-by: Min Qin <qinmin@chromium.org>
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#628893}
Reviewed-on:

https://chromium-review.googlesource.com/c/1455306
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Cr-Commit-Position: refs/branch-heads/3626@{#832}
Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437}

bu...@chops-service-accounts.iam.gserviceaccount.com <bu...@chops-service-accounts.iam.gserviceaccount.com> #24Feb 5, 2019 08:47PM

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src.git/+/2d7e342fe59600e1f8d1d6ca8e4591847d5fc3b3

commit 2d7e342fe59600e1f8d1d6ca8e4591847d5fc3b3
Author: Marijn Kruisselbrink <mek@chromium.org>
Date: Tue Feb 05 20:44:47 2019

Fix blob URLs in the chrome.downloads API with network service enabled.

Long term the chrome.downloads implementation should probably resolve
blob URLs in the renderer process before sending the IPC to the browser,
as that is the only way to guarantee that the blob URL can resolve
correctly, but this fix should at least for most cases.

TBR=mek@chromium.org

(cherry picked from commit f5534db9782f9bcb83e062e8bb6d341a458070a8)

Bug: 928307
Change-Id: I85b29c91ff1d89451811b30ea7a9f8d22f853ea2
Reviewed-on:

https://crrev.com/2d7e342fe59600e1f8d1d6ca8e4591847d5fc3b3/content/browser/download/download_manager_impl.cc

bu...@chops-service-accounts.iam.gserviceaccount.com <bu...@chops-service-accounts.iam.gserviceaccount.com> #25Feb 5, 2019 08:47PM

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src.git/+/eb0370beb11b22460b27e9c1a39940c6b735fe42

commit eb0370beb11b22460b27e9c1a39940c6b735fe42
Author: Marijn Kruisselbrink <mek@chromium.org>
Date: Tue Feb 05 20:45:45 2019

Fix blob URLs in the chrome.downloads API with network service enabled.

Long term the chrome.downloads implementation should probably resolve
blob URLs in the renderer process before sending the IPC to the browser,
as that is the only way to guarantee that the blob URL can resolve
correctly, but this fix should at least for most cases.

TBR=mek@chromium.org

(cherry picked from commit f5534db9782f9bcb83e062e8bb6d341a458070a8)

Bug: 928307
Change-Id: I85b29c91ff1d89451811b30ea7a9f8d22f853ea2
Reviewed-on:

https://chromium-review.googlesource.com/c/1455307
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Cr-Commit-Position: refs/branch-heads/3683@{#222}
Cr-Branched-From: e51029943e0a38dd794b73caaf6373d5496ae783-refs/heads/master@{#625896}
[modify]

https://crrev.com/eb0370beb11b22460b27e9c1a39940c6b735fe42/content/browser/download/download_manager_impl.cc

me...@chromium.org <me...@chromium.org> #26Feb 5, 2019 08:52PM

Marked as fixed.

[Empty comment from Monorail migration]

ja...@google.com <ja...@google.com> #27Feb 5, 2019 09:51PM

Thanks gtclaan@ for the report, Marijn for the quick fix, and Abdul for the merge approval!

gt...@gmail.com <gt...@gmail.com> #28Feb 6, 2019 07:11AM

Great work all! Your help is very much appreciated!

su...@chromium.org <su...@chromium.org> #29Feb 6, 2019 11:43AM

Able to reproduce this issue on Windows 10, Mac OS 10.13.6 and Ubuntu 14.04 on the reported version 72.0.3626.81 and the issue is fixed on the latest M-72 build 72.0.3626.96 as per

https://crbug.com/chromium/928307#c6.

1. Launched Chrome and enabled #network-service flag.
2. Navigated to chrome://extensions and turned on the 'Developer mode'.
3. Added the extension

928307-M72.mp4

2.5 MB

Download

cr...@appspot.gserviceaccount.com <cr...@appspot.gserviceaccount.com> #30Feb 7, 2019 03:08PM

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src.git/+/eb0370beb11b22460b27e9c1a39940c6b735fe42

Commit: eb0370beb11b22460b27e9c1a39940c6b735fe42
Author: mek@chromium.org
Commiter: mek@chromium.org
Date: 2019-02-05 20:45:45 +0000 UTC

Fix blob URLs in the chrome.downloads API with network service enabled.

Long term the chrome.downloads implementation should probably resolve
blob URLs in the renderer process before sending the IPC to the browser,
as that is the only way to guarantee that the blob URL can resolve
correctly, but this fix should at least for most cases.

TBR=mek@chromium.org

(cherry picked from commit f5534db9782f9bcb83e062e8bb6d341a458070a8)

Bug: 928307
Change-Id: I85b29c91ff1d89451811b30ea7a9f8d22f853ea2
Reviewed-on:

su...@chromium.org <su...@chromium.org> #31Feb 8, 2019 10:02AM

Able to reproduce this issue on Windows 10, Mac OS 10.13.6 and Ubuntu 17.10 on the reported version 72.0.3626.81 and the issue is fixed on the latest M-73 build 73.0.3683.27 by following the steps mentioned in

https://crbug.com/chromium/928307#c28.
Attached is the screen cast for reference.

Hence adding TE verified labels as the fix is working as intended.

Thanks..

928307-M73.mp4

4.2 MB

Download

is...@google.com <is...@google.com> #32Feb 8, 2019 10:02AM

This issue was migrated from

crbug.com/chromium/928307?no_tracker_redirect=1

[Multiple monorail components: Blink>Storage>FileAPI, Internals>Services>Network, Platform>Extensions]
[Monorail components added to Component Tags custom field.]

Issue 41439098

Description

Issue summary

Comments

su...@chromium.org <su...@chromium.org> #2Feb 4, 2019 05:43PM

ja...@chromium.org <ja...@chromium.org> #3Feb 4, 2019 06:26PM

me...@chromium.org <me...@chromium.org> #4Feb 4, 2019 06:48PM

me...@chromium.org <me...@chromium.org> #5Feb 4, 2019 06:59PM

gt...@gmail.com <gt...@gmail.com> #6Feb 4, 2019 07:04PM

gt...@gmail.com <gt...@gmail.com> #7Feb 4, 2019 07:07PM

me...@chromium.org <me...@chromium.org> #8Feb 4, 2019 07:26PM

gt...@gmail.com <gt...@gmail.com> #9Feb 4, 2019 07:29PM

me...@chromium.org <me...@chromium.org> #10Feb 4, 2019 07:35PM

me...@chromium.org <me...@chromium.org> #11Feb 4, 2019 07:40PM

ja...@chromium.org <ja...@chromium.org> #12Feb 4, 2019 08:05PM

ja...@chromium.org <ja...@chromium.org> #13Feb 4, 2019 08:10PM

gt...@gmail.com <gt...@gmail.com> #14Feb 4, 2019 09:47PM

bu...@chops-service-accounts.iam.gserviceaccount.com <bu...@chops-service-accounts.iam.gserviceaccount.com> #15Feb 4, 2019 10:13PM

me...@chromium.org <me...@chromium.org> #16Feb 4, 2019 10:20PM

sh...@chromium.org <sh...@chromium.org> #17Feb 4, 2019 10:22PM

vi...@chromium.org <vi...@chromium.org> #18Feb 5, 2019 06:10AM

su...@chromium.org <su...@chromium.org> #19Feb 5, 2019 12:34PM

ab...@google.com <ab...@google.com> #20Feb 5, 2019 05:48PM

me...@chromium.org <me...@chromium.org> #21Feb 5, 2019 05:50PM

ab...@google.com <ab...@google.com> #22Feb 5, 2019 08:27PM

cr...@appspot.gserviceaccount.com <cr...@appspot.gserviceaccount.com> #23Feb 5, 2019 08:46PM

bu...@chops-service-accounts.iam.gserviceaccount.com <bu...@chops-service-accounts.iam.gserviceaccount.com> #24Feb 5, 2019 08:47PM

bu...@chops-service-accounts.iam.gserviceaccount.com <bu...@chops-service-accounts.iam.gserviceaccount.com> #25Feb 5, 2019 08:47PM

me...@chromium.org <me...@chromium.org> #26Feb 5, 2019 08:52PM

ja...@google.com <ja...@google.com> #27Feb 5, 2019 09:51PM

gt...@gmail.com <gt...@gmail.com> #28Feb 6, 2019 07:11AM

su...@chromium.org <su...@chromium.org> #29Feb 6, 2019 11:43AM

cr...@appspot.gserviceaccount.com <cr...@appspot.gserviceaccount.com> #30Feb 7, 2019 03:08PM

su...@chromium.org <su...@chromium.org> #31Feb 8, 2019 10:02AM

is...@google.com <is...@google.com> #32Feb 8, 2019 10:02AM

Add comment

Issue metadata