Repository navigation
readAsDataURL should be more precise about the data URL contents #104
Description
Activity
See also whatwg/fetch#665 which this would tie into (if someone wants to work on that, feel free, happy to assist).
Re: "creating the string from the contents of the
typeattribute" - just a note in case someone tackles this. Beware of the gotcha associated with #43 - namely, as the spec is currently written, the value returned by thetypeattribute's getter and the internal type of the blob (which isn't clearly documented) differ if the type is not a parseable MIME type.Regarding the mime type, WPT tests that an unspecified mime type should be application/octet-stream which all browser implementations have aligned on.
Though, saying that - it's not clear whether the mime type should fall back to that as well for a mime type which is parsable or not.
Based on the following test, I think the logic is probably just if it is not an empty string in all browsers at least:
async_test(function(testCase) { var blob = new Blob(["TEST"], { type: 'not a mime type' }); var reader = new FileReader(); reader.onload = this.step_func(function() { assert_equals(reader.result, "data:not a mime type;base64,VEVTVA=="); testCase.done(); }); reader.readAsDataURL(blob); }, 'readAsDataURL result for Blob with unparsable MIME type');
There's a separate issue on making sure
typeis always valid. We should really attempt to fix that.Reacted by Shannon Booth
In particular, it appears all browsers base64-encode the contents; see jsdom/jsdom#2269 for the original report.
Probably it'd be best to give the exact algorithm for creating the string from the contents of the
typeattribute and the bytes of the Blob.