FileReader readAsDataURL guesses MIME-Type when given a Blob without a type property.
Reported by
shi...@inkling.com,
Oct 30
|
||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.67 Safari/537.36
Steps to reproduce the problem:
1. Create a new Blob from unsigned 8-bit int array with option { type: '' }
2. Create a new FileReader.
3. Read the Blob as a data URL.
Example:
const decodedURL = atob('someEncodedURL');
const decodedArr = decodedURL.split('');
const arr = new Uint8Array(decodedArr);
const blobby = new Blob(arr, { type: '' });
const fr = new FileReader();
fr.readAsDataURL(blobby);
What is the expected behavior?
Per the current spec, the FileReader should not interpret a MIME-type.
https://w3c.github.io/FileAPI/#readAsDataURL
It should not have a MIME-type: 'data:;base64,...<url>'
What went wrong?
The resulting URL has a MIME-type: 'data:application/octet-stream;base64,...<url>'
Did this work before? Yes Unknown, I suspect 69.
Does this work in other browsers? No
FireFox: matches Chrome behavior
Safari: follows spec
Edge: unknown
Chrome version: 70.0.3538.67 Channel: n/a
OS Version: OS X 10.13.6
Flash Version:
,
Oct 30
,
Oct 31
I can add a URL sample but I really don't feel that it is necessary for the reproduction steps.
Here are minimal repro steps:
const fileReader = new FileReader();
await fileReader.readAsDataURL(new Blob(['1'], { type: '' }));
console.log(fileReader.result === 'data:;base64,MQ==') //expect true but get false
,
Oct 31
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 31
Able to reproduce the issue on reported chrome version 70.0.3538.67 also on latest chrome 72.0.3596.0 using Mac 10.14.0, Ubuntu 17.10 and Windows 10. Same behavior is seen on M63 hence considering it as non-regression and marking it as Untriaged. Note: From M-60 to M-62 observed Uncaught error and from M-63 seen false. Removing Needs-Bisect label to it. Thanks!
,
Oct 31
,
Nov 2
Working as intended - this change was made for interop reasons to match Firefox behavior: see issue 48368
,
Nov 2
Then is there an update to the FileAPI spec forthcoming? https://w3c.github.io/FileAPI/#readAsDataURL Specifically: 7 -> 2 'If the type attribute is not available on the blob return a Data URL without a media-type.' I believe there should be a valid case for not following the spec.
,
Nov 6
See for example https://github.com/w3c/FileAPI/issues/104, updating the spec to be more precise about data URL format is definitely on the radar, and will probably involve writing web-platform-tests for edge cases like this as well. Feel free to leave a comment on that issue to make sure this particular edge case is taken into account when I (or somebody else) finally gets around to it... |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by phanindra.mandapaka@chromium.org
, Oct 30Labels: Needs-Feedback Triaged-ET