Repository navigation
MDN says FileReader.result is a String or ArrayBuffer, but Dartium says it's a Uint8List #17956
Description
MDN docs say FileReader.result is "A string or an ArrayBuffer which depends on the method used to initiate the read operation.": https://developer.mozilla.org/en-US/docs/Web/API/FileReader.result
The API docs say result is an object: https://api.dartlang.org/apidocs/channels/stable/dartdoc-viewer/dart-dom-html.FileReader#id_result
In dartium, apparently FileReader.result is a Uint8List: (see screenshot)
Dart does not have a ArrayBuffer, but it does have a ByteBuffer.
decodeAudioData needs a ByteBuffer (previously, ArrayBuffer in JS world). See https://api.dartlang.org/apidocs/channels/stable/dartdoc-viewer/dart-dom-web_audio.AudioContext#id_decodeAudioData
In JS code, I would get an ArrayBuffer from FileReader, and pass that decodeAudioData. Now, I get Uint8List from FileReader, so I need to convert.
Attachment:
[Screen Shot 2014-04-01 at 6.19.17 PM.png](https://storage.googleapis.com/google-code-attachments/dart/issue-17956/comment-0/Screen Shot 2014-04-01 at 6.19.17 PM.png) (208.11 KB)
Activity
sethladd commentedon Apr 2, 2014
Related to https://code.google.com/p/dart/issues/detail?id=10136 it looks like.
sethladd commentedon Apr 2, 2014
Marked this as being blocked by #10136.
kevmoo commentedon Apr 7, 2014
Removed Area-HTML label.
Added Area-Library, Library-Html labels.
rakudrama commentedon Apr 11, 2014
Apparently I made the change: https://code.google.com/p/dart/issues/detail?id=17058
So the dart2js library also returns a Uint8List.
At least they are consistent, and tested.
I should have written some documentation at the time.
The 'fix' is to pass result.buffer. This assumes you know that the FileReader result is a Uint8List that is a total view of a buffer. I am not totally happy with this change, since a Uint8List might be a view of a piece of the buffer. It is an act of faith that the view is total. Passing result.buffer would pass more data than intended if the view was a partial view.
decodeAudioData is also a problem. The W3 spec http://www.w3.org/TR/webaudio/ says the ArrayBuffer is temporarily neutered during the asynchronous decoding. AFAIK there is no way to do this with the VM types.
I expect the decodeAudioData spec to change since this is also a problem in JavaScript browser implementations, impeding more efficient typed data implementations.
The point-change is to document the new behaviour. It is more discoverable than the old in the editor (.buffer has a matching type, harder to discover
new Uint8List.view(buffer)for other use cases like using dart:convert on FileReader.result; but more advanced completions might make this point moot (e.g http://www.cs.yale.edu/homes/piskac/publications/GveroETAL13Completion.pdf))The bigger change that needs to happen is to light a fire under issue #10136 and review all uses typed data to ensure the browser platform can properly be supported.
Set owner to @sethladd.
sethladd commentedon Apr 14, 2014
Removed the owner.
Removed Type-Defect label.
Added Type-Task, Docs-API labels.
kwalrath commentedon Jun 4, 2014
Removed Type-Task label.
Added Type-Documentation label.
matanlurey commentedon Jun 19, 2018
Please re-open if this is still the case with the latest
2.0.0-devSDK.