New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 389642 link

Starred by 7 users

Issue metadata

Status: Duplicate
Owner: ----
Closed: Jan 2016
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Sign in to add a comment

Cannot save object URLs

Reported by, Jun 27 2014

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36

Steps to reproduce the problem:
1. Run open(URL.createObjectURL(new Blob))
2. Press Ctrl+S or go to Menu->Save page as...

What is the expected behavior?
Saving is enabled.

What went wrong?
Saving is disabled.

Did this work before? No 

Chrome version: 35.0.1916.153  Channel: stable
OS Version: 6.3
Flash Version: Shockwave Flash 14.0 r0

It is already possible to save object URLs using <a download>. There is no reason to restrict manual saving by the user.

Note: This is a duplicate of

I do not have commit access, so I cannot re-open that issue.
Labels: Needs-Feedback
Unable to reproduce the issue on Windows and Mac - chrome version 35.0.1916.153 and canary 38.0.2081.0.

Able to save the page after running open(URL.createObjectURL(new Blob)) in the console of any webpage.
Screen Shot 2014-07-07 at 4.25.01 PM.png
68.1 KB View Download

Comment 2 by, Jul 7 2014

"Save page as..." is grayed out for me on Chrome 35 on the latest versions of Windows and Chrome OS.

Chrome 35 on Windows 8.1:

Chrome OS 35:

Comment 3 by, Jul 7 2014

Oh, I see that you're doing "Save as..." from the page that called the code.

I'm stating that you cannot save the object URL, not the page you are currently on.

Comment 4 by, Jul 7 2014

In order to reproduce this, enter that code on something like so the popup blocker understands that it's the result of user input.
This issue still exists on Chrome 43.0.2348.3 canary (64-bit). Another way of reproducing it without overriding the popup blocker is to cut and paste the URL.createObjectURL() result into the omnibox. Note that comment #1 did not test the right thing (as noted by comment #3).

This can be fixed with a single line of code, marking the blob scheme as savable:

diff --git a/content/common/ b/content/common/
index c149aae..b7f0406 100644
--- a/content/common/
+++ b/content/common/
@@ -21,6 +21,7 @@ const char* const kDefaultSavableSchemes[] = {
+  url::kBlobScheme,

I tested this patch on a recent (about a month old) Chromium source tree and blob documents were allowed to be saved.

Given that data URLs are enabled, I don't see why blob URLs should not also be enabled. My use case is for Chrome extensions and apps that produce XML output - I want to display the result in the browser (with XSLT) and allow the user to save the XML. This can be done with a data URL but only if the URL size is under 2 MB.

The last bug database activity for, the only project person registered for updates for this bug, was 7 months ago, so I wonder if they are still working on Chromium. If not, is anyone going to see this or does it stay in Needs-Feedback state forever?
Verified the issue on Latest Stable# 47.0.2526.80 and Latest Canary# 49.0.2491.0 on Windows and could not reproduce the issue.
@iSephr -- Could you please re-check on Latest version mentioned and if reproducible please provide us the screen cast of the issue.
Thanks in Advance.

Comment 7 by, Dec 14 2015

@mrschan...: I attached a screenshot from 47.0.2526.80 m (64-bit).
Image 2015-12-14 at 2.04.41 PM.png
38.7 KB View Download

Comment 8 by, Dec 14 2015

Same in the context menu for the page.
Image 2015-12-14 at 2.08.05 PM.png
26.9 KB View Download
Labels: -Needs-Feedback
Mergedinto: 119129
Status: Duplicate
Issue similar to earlier reported issue '119129' hence merging.

Thank you!

Comment 10 by, Jan 29 2016

I don't have access to issue 119129.

Comment 11 by, Jan 29 2016

What is the status of issue 119129? Started, WontFix, etc?

Comment 12 by, Jan 29 2016

Also,  issue 91158  came even earlier than issue 119129. Shouldn't issue 119129 be marked duplicate of  issue 91158 , and  issue 91158  be re-opened?
I don't think that duping to issue 119129 is appropriate. That issue is a proposal to *disable* downloads from certain URL schemes, and it was eventually rejected and marked WontFix in 2012.

This issue is almost exactly the opposite. It is a proposal to *enable* downloads from the blob scheme.

While you might claim that they are both about whether downloads from particular schemes are allowed or not, merging this issue to another one years old, marked WontFix, and restricted from public view doesn't seem like that helps to get it resolved. Either issue 119129 should be reopened because it now has wider and unresolved scope, or  issue 389642  should be addressed separately. I think the latter option, leaving it as a separate issue, is highly preferable.

Comment 14 by, May 27 2016

ashejole: This issue is not similar to 119129, it's the exact opposite. Please look at my screenshots to understand what is happening.
Since this is about blobs, +dmurph to assess the bug.

Comment 16 by, May 28 2016

Here is an better testcase:

1. Enter this in your console: location.href = URL.createObjectURL(new Blob)
2. Right click inside the page and try to click "Save as..."

Sign in to add a comment