MDN says FileReader.result is a String or ArrayBuffer, but Dartium says it's a Uint8List

[sethladd]

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)

[sethladd]

Related to https://code.google.com/p/dart/issues/detail?id=10136 it looks like.

[sethladd]

Marked this as being blocked by #10136.

[kevmoo]

Removed Area-HTML label.
Added Area-Library, Library-Html labels.

[rakudrama]

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]

Removed the owner.
Removed Type-Defect label.
Added Type-Task, Docs-API labels.

[kwalrath]

Removed Type-Task label.
Added Type-Documentation label.