Bug 197441 – Blob downloads not working on pinned pages

• Status: RESOLVED
• Resolution: INVALID
• Component: JavaScriptCore

[Michaela Merz]

Our web-service generates downloadable files by assembling binary blocks into blobs which are made downloadable via "a href" and download attribute. This works fine on all browsers (Chrome, Firefox, Epiphany (WebKit 2.18.6) and it used to work in Safari. However - it doesn't work anymore for Safari version 12.1 (14607.1.40.1.4). Instead of downloading the data, Safari opens a new tab and displays the "WebKitBlobResource error 1 . We're using no frames, no target attribute and even with target="_self" , the error occurs.

After an exhausting search we traced the error to 

--- Pseudo-Code - WILL NOT WORK IN CURRENT SAFARI

function
prepare(blob)
{
   var URL = window.URL || window.webkitURL;
   var image = URL.createObjectURL(blob);
   showDownload(image)
}

function
showDownload(i)
{
   $('#link').prop('href',i);
   $('#link').attr('download',"name.jpg")
}

--- Pseudo-Code - WORKS IN CURRENT SAFARI

var URL = window.URL || window.webkitURL;

function
prepare(blob)
{
   var image = URL.createObjectURL(blob);
   showDownload(image)
}

function
showDownload(i)
{
   $('#link').prop('href',i);
   $('#link').attr('download',"name.jpg")
}


---- END OF PSEUDOCODE

See https://packfrog.com/test.php for details

In other words: If the variable "URL" is declared globally, the process works as expected. This leads to the conclusion that the reference to window.webkitURL is deleted or no longer available when function "prepare" is terminated. This seems to be incorrect. It should also not just open a tab but generate a meaningful error message.

Michaela

[Chris Dumez]

Thanks for the bug report and the reproduction case. Did you try Safari Technology Preview? I have just tried here with https://packfrog.com/test.php and it appears to be working fine. It is possible this bug has already fixed fixed in STP.

[Michaela Merz]

Chris:

Unfortunately the development team has only one Safari capable computer and that machine was in high demand in order to understand and to work around this bug. It was due to user complaints that we became aware of the problem. It is sad that we can't use Safari on different development platforms but well, that's just the way it is. Were you able to confirm the bug using the current version of Safari?

Michaela

[Chris Dumez]

I have just installed macOS 10.4.4 with Safari 12.1 on a fresh partition. I went to https://packfrog.com/test.php and clicked on the link. I then ended up with an image named willi.png in my Downloads folder.

It appears I am not able to reproduce the issue you report with your test case. Any idea what I am doing differently?

[Chris C]

We are also having this exact same issue, but only one some Macs, just not mine. So what worked well in development didn't work so well in production.

Not affected: 
Mac 5K 2019 Edition Mojave 10.14.4 , Safari 12.1 (14607.1.40.1.4)

Affected:
Mac 5K 2017 10.14.4 , Safari 12.1 (14607.1.40.1.4))
other Macs 2018, running High Sierra

Interestingly, both Mac 5Ks were running the same latest OS and Safari versions. I've also checked Safari extensions, settings etc. and couldn't find anything that could explain the bug. It appears therefore that YOU NEED TO TEST THIS BUG ON DIFFERENT MACHINES TILL YOU FIND ONE WITH THE BUG.

[Chris C]

(In reply to Michaela Merz from comment #0)

> In other words: If the variable "URL" is declared globally, the process
> works as expected. 

We've tried it with our own code internally, declaring var URL = window.URL globally and then using that within functions to "URL.createObjectURL(csvData)" but it didn't work for us.

Instead of image or PDFs, we're trying to download a CSV.

[Chris C]

We've also discovered something new:

The link appears in DOM like so:

<a href="blob:https://ourdomain.com/e0ea076d-e9a3-4aa4-96cf-cdb16c238b29" target="_self" download="download.csv">Download CSV</a>

When clicked, it opens up a tab to a *different* URL: 

Tab URL: blob:htts://ourdomain.com/a1a9da-a638-426a-b06a-e5aee5729f9c

When clicked again, yet a different URL (different UUID) is called.

However, when we manually copy the href "blob:https://ourdomain.com/e0ea076d-e9a3-4aa4-96cf-cdb16c238b29" into the browser address bar, it does return the CSV data.

So it appears that 
1) The href link is correct but
2) Clicking it each time calls a different random object URL.

[Michaela Merz]

My "Mac" man told me, that he installed some kind of an update yesterday concerning Xcode 10.2.1 - curiously enough, the error disappeared after that. In any way - we're continuing to investigate as this error ist very troubling for our users.

[Chris C]

(In reply to Michaela Merz from comment #7)
> My "Mac" man told me, that he installed some kind of an update yesterday
> concerning Xcode 10.2.1 - curiously enough, the error disappeared after
> that. In any way - we're continuing to investigate as this error ist very
> troubling for our users.

I thought there might be something there, since I have Xcode on my Mac and MacBook (both work fine) and the other Macs that had the bug didn't have Xcode.

Unfortunately the first Macbook I tried (running High Sierra, Safari 12.1 (13607.1.40.1.4) that didn't have Xcode, *worked fine* too.

[Michaela Merz]

This bug is getting weirder by the minute. The "fix" I proposed is not working. Well it is - for some folks but it is not for others. We have users that can't download real data but can use the test while others get errors with the test but can download real data just fine.

I am now suspecting that it is a timing problem or race condition, maybe even something we (as Javascript developers) can't circumvent. I am confirming @Chris_C observations that the very same code works for some people but won't work for others even if the browser versions are identical. 

Needless to say everything works just fine in any other browser and operating system. 

This is a serious problem for us.

[Chris Dumez]

I agree, this is likely a race condition.

[Chris Dumez]

If somebody that can reproduce can attach a sysdiagnose (right after reproducing the issue, ideally letting me know which time you reproduced the issue), it may also help.

[Chris C]

(In reply to Chris Dumez from comment #10)
> I agree, this is likely a race condition.

Even so, so far it appears that the bug (or lack of) is consistent across specific devices i.e. if the bug doesn't show for my Mac, it always doesn't show; if it shows for a particular user's Mac, it always doesn't show; despite having the same OS and Browser version. So it doesn't appear to be based on time alone, but possibly hardware-related.

One other clue that might be helpful in locating the bug when it does occur is in https://bugs.webkit.org/show_bug.cgi?id=197441#c6 where we found that clicking the link actually goes to a new non-existant blob URL each time.

[Michaela Merz]

This is -sort of- the way we are experiencing the bug too. However - changing the source - or running it through the closure compiler - changes this behavior in a way that some users don't experience the error anymore while others who had no problems suddenly can't download anymore.

[Gints]

Not sure if this is helpful. Here's my situation and the way I fixed it. I'm running Safari 12.1

//I created a Blob from data, and appended that blob to more data which mostly failed with "WebKitBlobResource error 1"

const blob1 = new Blob([1,2,3],{type: "octet/stream"});
const finalBlob = new Blob([blob1,[4,5,6]],{type: "octet/stream"});
window.URL.createObjectURL(finalBlob); // fails 8/10 times on Safari

//To fix it I first gathered the data arrays and created a single Blob instead

const data = [[1,2,3],[4,5,6]]
const finalBlob = new Blob(data,{type: "octet/stream"});
window.URL.createObjectURL(finalBlob); // works always

[Leo Gala]

We're also having the same issue, but on Safari Mobile.

I have tried the workarounds listed in this issue and in https://bugs.webkit.org/show_bug.cgi?id=190351 to no avail.

Is there a solution for this bug yet? Is this issue still actively followed? Please update if so.

Thanks!

[JM]

I found a way to reliably reproduce the issue: Pin the tab. Unpinning the tab will make it go away again.

I have not been able to reproduce the issue an any Mac yet that does not have pins (n=6), would be interested to hear if anyone found a counter example.

(Found in a Reddit thread from 6 months ago where Protonmail support mentions this a known issue with Safari, and it's already been reported to Apple.)

[Radar WebKit Bug Importer]

<rdar://problem/52507027>

[JM]

I have confirmed with customers who had this problem that the issue goes away once the unpin the tab, so it may make sense to update the bug description to "Blob downloads not working on pinned pages"

[Chris C]

I can also confirm that this bug went away for affected Macs after they unpinned the tab.

[Chris Dumez]

I am able to reproduce by loading https://packfrog.com/test.php into a tab and pinning it. Crazy.. I have no idea (yet) how pinning a tab could impact WebKit.

[Chris Dumez]

This is a Safari issue so it is tracked by radar. The radar has been sent to the appropriate team. We know what's going on now.

Thank you for figuring out this was caused by pinned tabs.

[Chris Dumez]

*** Bug 209172 has been marked as a duplicate of this bug. ***