New issue
Advanced search Search tips

Issue 91158 link

Starred by 11 users

Issue metadata

Status: Duplicate
Owner: ----
Closed: May 2012
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Blocked on:
issue 114484

issue 68356

  • Only users with Commit permission may comment.

Sign in to add a comment

Cannot save data: URIs, object URLs, or filesystem: URLs

Reported by, Aug 1 2011

Issue description

Chrome Version       : 12.0.742.122
URLs (if applicable) : data:,try%20to%20save%20this
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: OK
  Firefox 4.x: OK
    IE 10 PP2: N/A (maybe object URLs will work by release)

What steps will reproduce the problem?
1. Navigate to a data: URI, object URL, or filesystem: URL.
2. Push Ctrl+S or Wrench->Save page as...

What is the expected result?

Save file dialog appears.

What happens instead?

Option to save is disabled.

Please provide any additional information below. Attach a screenshot if

A workaround that only applies to audio and raster media formats is to right click on the media and click save as from there.
Labels: -Area-Undefined Area-Internals Feature-Downloads
Status: Available
This works for me on filesystem URLs (file://....).  I could imagine that it not working on data urls is working as designed; like POSTs, data urls might change state, and so we don't want to enable re-downloading them.

Blocking: 68356

Comment 4 by, Feb 15 2012

Blockedon: 114484
Status: Started
This will be fixed by 114484.

Comment 5 by, Feb 15 2012

Sorry--should have been more specific.  The filesystem URLs should be savable after 114484 is fixed.

Comment 6 by, Apr 4 2012

Owner: ----
Status: Unconfirmed
I've verified that the fix for 114484 fixed filesystem URLs.

BTW rdsmith, that's e.g. filesystem:, not file://stuff.
Labels: Action-FeedbackNeeded
@iSephyr:  Is this still an issue?  If so, can you give me a sense as to the use case for wanting to save data: & object: URLs?  There's a recent change we made which may have disabled this if it was working (for data: URLs at least) for security reasons, so I need the background in order to weigh the security vs. user experience issues.

Comment 8 by, Apr 16 2012

Yes, this is still an issue. Navigate to "data:,test" and attempt to save the file.
We do at this point intentionally block downloading from data: URLs as a security filter.  Can you give me a sense as to what the purpose is for which you'd like to be able to do that?

I'm not sure what iSephyr's use case is, but I'm looking for a solution either to save from a data:url or a filesystem:file because I'm building a Chrome extension that needs to export a file for the user. I want to avoid using a server because the user's data is very private. Thus I'm looking for an entirely local solution- generate and save the file using javascript.

Comment 11 by, Apr 21 2012

@Randy Many sites use open(canvas.toDataURL()) to let users save canvases as Chrome doesn't provide a "Save As…" option in the canvas context menu. Of course you should be using BlobBuilder + URL.createObjectURL + a.@downloed to save generated content, but as it stands, very few sites do this, and Chrome blocking data: URI downloads breaks these sites (primarily canvas-powered image editors)

@Owen Use BlobBuilder + URL.createObjectURL + a.@download to save generated content. If you need to trigger a download without having the user click on a link, make the a.@download link and then do:

var click = document.createEvent("Event");
click.initEvent("click", true, true);

Comment 12 by, Apr 21 2012

Also, Owen, it's impossible for a UGC link to go to a malicious object URL, as object URLs must be generated through the page's scripts. The <a>.@download solution was not present at the time of reporting this issue, and is a newer workaround to the issue.

I don't see any real security gains in the blocking of saving data: URIs and object URLs, as you can still generate any content and save it through <a>.@download. The possibility that some people may generate malware executables isn't reason enough to block this. It's not like websites can't just serve the executables themselves.

Comment 13 by, Apr 21 2012

Oops; in comment #12 I meant Randy.
@iSepher thanks for the tip. Works great!

The data: part of this is issue 119129, which was fixed last week.
Mergedinto: 119129
Status: Duplicate
…and filesystem: is fixed according to comment 6. So I think this is fixed on trunk.

Comment 17 by, May 1 2012

I don't have access to issue 119129; does it address saving object URLs too ("blob:" in WebKit)?
@iSephr: We never disabled blob: saving; it should (still?  always?)  work.  If it doesn't, file a new bug and we'll figure it out.

Comment 19 by, May 9 2012

@rdsmith: It doesn't in Chrome stable, and that was one of the points of this bug (all generated content can't be Ctrl+S'd). Does issue 119129 deal with "Save page as"/Ctrl+S in general at all?

Quick testcase: open(webkitURL.createObjectURL((new WebKitBlobBuilder).getBlob("text/plain")))
The "Save As..." menu is still disabled in Chrome 19. For example, browse to


And right-click. "Save As..." is disabled. Chrome 21 appears to be working, however (on OS X).
Blocking: chromium:68356
Project Member

Comment 22 by, Oct 13 2012

Blockedon: -chromium:114484 chromium:114484
Blocking: -chromium:68356
Labels: Restrict-AddIssueComment-Commit
Mergedinto: chromium:119129
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 23 by, Mar 9 2013

Labels: -Action-FeedbackNeeded Needs-Feedback
Project Member

Comment 24 by, Mar 10 2013

Labels: -Area-Internals -Feature-Downloads Cr-Internals Cr-UI-Browser-Downloads

Sign in to add a comment