IsArrayLike needs to check for various typed array stuff

RESOLVED FIXED

Status

()

Core
DOM
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: bz, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Basically, any typed-array-thing (ArrayBuffer, ArrayBufferView, any of the typed arrays) that supports indexed access needs to return true from IsArrayLike.
I'm not sure I follow. Which of these should return true? (Note that some of these statements will only be true after I land everything in my patch stack.)

 - ArrayBuffer: does not support indexed access.

 - DataView: it is an ArrayBufferView, but it does not support indexed access. You need to use typed getters like getUint8(index) to access the ArrayBuffer data.

 - Float32Array.prototype (or any typedarray.prototype): "supports" indexed access, but is always length zero.

 - A typed array view of a neutered ArrayBuffer: we haven't 100% pinned down the semantics here. Either it acts as if it is length zero, or it throws an exception if you try to access it.

If the answer is "none of the above", then I think I know what you should use, but I'll wait until it makes it through review first.
Per WebIDL, I need to return true here for instances of interfaces that have indexed properties.

Given your description in comment 1, I definitely want to return false for ArrayBuffer DataView, and the typed array protos.

Not sure about typed arrays views of a neutered ArrayBuffer.  Cameron?

The fact that our typed array impl is only loosely related to the typed array spec is a bit annoying.  :(
I would say it's simpler to return true for typed array views always, without looking to see if the ArrayBuffer is neutered.
Bug 748267 just made us use JS_IsTypedArrayObject here.  sfink, I assume that tests false for dataviews?
Yes, that is correct.
OK, then this is fixed.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Depends on: 748267
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.