44

I'm writing a chrome extension which does the following:

  1. Downloads a file from a website to memory using XMLHttpRequest
  2. Adds additional data to the file and then base64 encodes the result to the variable total_encoded_data
  3. Offers the data to the user using <a href=data:application/octet-stream;charset=utf-8;base64,' + total_encoded_data+' download='file.bin'>Click to Download</a>. Where total_encoded_data is added to href using jQuery.

I have found, through a manual binary search, that if the size of total_encoded_data is greater than 2097100 characters, then I will get an Aw, Snap message when I click the link. If the size is smaller, then I can download as expected.

In addition to testing the filesize, I also used atoi to ensure that the base64 encoding is valid, and it operates without error.

The Aw, Snap messages don't produce any crash reports in chrome://crashes nor any unexpected output in the chrome_debug.log

How do I avoid an Aw, Snap message when serving a data uri where the base64 encoded string length is greater than 2097100?

1
  • 1
    perhaps this trivia tidbit might be of some use in designing a workaround strategy - 2097100 + 52 = 8^7 aka 2^21. As for even closer to that number, 2097100 + 1 neatly factors into 1399 x 1499 Jun 19, 2022 at 20:06

1 Answer 1

58

It's a known chromium bug. The recommended workaround is to use a blob URL. Also see Creating a Blob from a base64 string in JavaScript.

9
  • 35
    3.5 years later... still not fixed. God damn it, Chrome.
    – kangax
    Sep 27, 2014 at 11:44
  • 6
    Almost 7 years later... and solved the same old issue with the blob url trick!
    – aBertrand
    Dec 19, 2016 at 7:09
  • 1
    If anybody is wondering, the maximum size is based on 2MB in bytes... 2 * 1024 * 1024 bytes.
    – PaulMest
    Oct 20, 2017 at 8:23
  • 2
    Honestly guys this is ridiculous, it's almost 2018 and still there... I know why I dumped Apple... Unfortunately I have lots of clients with iPhones raises fist :)
    – megachill
    Nov 7, 2017 at 13:59
  • 1
    2020 and we're still waiting!
    – user11153
    Mar 27, 2020 at 9:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.