Bug 190351 – REGRESSION (Safari 12): Download of Blob URL fails

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit Misc.

[Iain]

Created attachment 351778 [details]
Download methods

Overview:
In our webapp construct 3 users can download a copy of their project. When saving projects are serialized into a blob ( zip format ) on the client side. To download the file we create a Blob URL, attach it to a new HTMLAnchorElement, specify the "download" attribute as the file name ( "myproject.c3p" ) and use the HTMLElement.prototype.click function. This method works correctly in Safari 11 and in chrome. However, now it opens a new tab displaying a WebKitBlobResource error 1 and no further information.

I think this may be related to the content blocker. On the first attempt to repeat this a "popup blocked" error will appear in the address bar and allowing it will download and unzip the project into a folder called "unknown" ( which I consider broken also ). Subsequent attempts will display the WebkitBlobResource error.

I have attempted to create a simple replication for this, but even when copying the exact code into a new document and calling in the same fashion ( the development tools REPL ) it only repeats in the actual web application.

I have included the download methods, but it's fairly standard stuff.

Steps to reproduce:
1. Visit https://editor.construct.net
2. Select "new project"
3. Select "menu > project > save as > download a copy"
4. Select "ok" ( uses default name )
5. Allow popup
6. Observe "unknown" folder appearing in downloads folder
7. Repeat steps 2 - 4
8. Observe error tab

Actual results:
A new tab displaying the error: Safari can't open the page "blob:https://editor.construct.net/[ blob id ]". The error is: "The operation couldn't be completed. (WebkitBlobResource error 1.)" (WebkitBlobResource:1)

Expected Results:
A new file in the downloads folder called "New project.c3p"

[Radar WebKit Bug Importer]

<rdar://problem/45091181>

[Chris Dumez]

Issue seems to come from the fact that target=_blank is used:
1. This triggers Safari's popup blocker. If you allow the popup later on, the filename is wrong because Safari does not know about the download attribute.
2. If popups are allowed, WebKit tries to *load* the blob instead of *downloading* it, thus the network error. This is due to a bug in our createNewWindow code path which I will fix.

[Chris Dumez]

Created attachment 351882 [details]
Patch

[Chris Dumez]

In a follow-up, I will look into ignoring the target when the download attribute is present. The HTML spec says to download the hyperlink instead of following the hyperlink. Only the "following the hyperlink" algorithm checks the frame name.

[Geoffrey Garen]

Comment on attachment 351882 [details]
Patch

r=me

[Ashley Gullen]

Ah, thanks for the tip about target=_blank - setting target=_self on any download attribute links seems to work around it. We'll ship this workaround soon so to continue reproducing the issue use the following link which will use a specific version of our PWA: https://editor.construct.net/r121/

[Chris Dumez]

Created attachment 351891 [details]
Patch

[Chris Dumez]

(In reply to Ashley Gullen from comment #6)
> Ah, thanks for the tip about target=_blank - setting target=_self on any
> download attribute links seems to work around it. We'll ship this workaround
> soon so to continue reproducing the issue use the following link which will
> use a specific version of our PWA: https://editor.construct.net/r121/

Great, thanks.

[WebKit Commit Bot]

Comment on attachment 351891 [details]
Patch

Clearing flags on attachment: 351891

Committed r236970: <https://trac.webkit.org/changeset/236970>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Chris Dumez]

Follow-up to avoid Safari's popup blocking at Bug 190408.

[Michaela Merz]

Unfortunately - it's not fixed. We are running into the same problem. A blob is assembled in Javascript, it's set into a download-URL with download attribute and it can be downloaded with Chrome, Firefox and Epiphany (webkit2gtk-4.0). We are not using frames, there's no difference with target="_self" or no target attribute, the error appears regardless of Content-Security-Settings and there is no warning or error on the console. 

Safari just opens a new tab and displays the "WebKitBlobResource error 1.). It worked fine in previous versions of Safari (on MacOS). 

Copying the generated BLOB:url into safari's URL bar allows the download of the data. 

Safari Version 12.1 (14607.1.40.1.4)

[Ashley Gullen]

You should probably file a new issue for that, it sounds different to this one if the target doesn't affect it.

[Michaela Merz]

It seems to be related as it behaves exactly like the original bug as posted. Only difference: We are not using iframe and target attributes. We tried with target="_self" but that didn't influence the bug. Safari just opens a new tab and displays the error.

[Michaela Merz]

Here's an update to the bug:

Test on Image in blob.

I can .. right click open the context-menu for a blob URL and 

.. Open in new tab: Displays Image
.. Open in new page: Displays Image 
.. Download: Downloads  the image

The *only* bug is that Safari opens a new tab after clicking the "a href" and displays the WebKitBlobResource error 1. It completely ignores the download attribute (for this blob) and it opens a new tab for now reason.

[Ashley Gullen]

I really think you should file a new issue. This is a closed issue and people tend to stop looking at them once they're marked fixed. And it's entirely possible there are two separate problems with similar looking symptoms.

[Chris Dumez]

(In reply to Ashley Gullen from comment #16)
> I really think you should file a new issue. This is a closed issue and
> people tend to stop looking at them once they're marked fixed. And it's
> entirely possible there are two separate problems with similar looking
> symptoms.

Yes, please file a new bug with your repro steps and cc me.

[Andy Schmidt]

New bug created for the never-fixed additional circumstances:
https://bugs.webkit.org/show_bug.cgi?id=211234

Still happening as recent as Safari 13.1 on iOS 13.4.

[Andy Schmidt]

(In reply to Chris Dumez from comment #17)
> (In reply to Ashley Gullen from comment #16)
> > I really think you should file a new issue. This is a closed issue and
> > people tend to stop looking at them once they're marked fixed. And it's
> > entirely possible there are two separate problems with similar looking
> > symptoms.
> 
> Yes, please file a new bug with your repro steps and cc me.

New bug created for the never-fixed additional circumstances:
https://bugs.webkit.org/show_bug.cgi?id=211234

Still happening as recent as Safari 13.1 on iOS 13.4.

The issues is still relevant in Safari 14.2, WebKit 16612.1.17.10.5 and Version 14.1.1 (16611.2.7.1.4) on macOS 11.4 (20F71).

The workaround to create a workable link was to add the "download" attribute to a-tag: 

<a href=blobURL download=file.name>text</a>

In that way Safari downloads a file without following the link.