Bugzilla

It's a bit strange, though, that test_objectgrips-20.js passes for workers when removing the code from bug 1522244. But in practice it doesn't work, calling the getter throws.

Interestingly, doing
```js
return new globalThis[object.class](object.unsafeDereference()).length;
```
seems to work fine, the downside is that the data is copied.

So in fact I think that this is a JS problem, all steps performed by [`get %TypedArray%.prototype.length`](https://tc39.github.io/ecma262/#sec-get-%typedarray%.prototype.length) should also happen in [`TypedArray(typedArray)`](https://tc39.github.io/ecma262/#sec-typedarray-typedarray), so it doesn't make sense that the former throws and the latter does not.

It doesn't help that the error is an Opaque error, so I can't read the message. And probably the code runs in an invisibleToDebugger compartment, I can't debug it. I guess I should debug the C++ instead...

(In reply to Brian Hackett (:bhackett) from comment #4)
> philosophically I feel that calling .length on the typed array in the debuggee is the right thing to do.

I disagree (bug 1406182). If you have `var arr = Object.setPrototypeOf(new Uint8Array([1,2,3]), null)`, there is no `arr.length`, but you can still use `arr[0]`, `arr[1]`, etc. to access the data. So the devtools shouldn't hide this data.

That said, if the [[ArrayLength]] cannot be easily accessed in workers, then using `object.proto.proto.getOwnPropertyDescriptor("length").get` instead doesn't make sense because it makes various unreliable assumptions. So I would agree to change it to the simpler `DevToolsUtils.getProperty(object, "length") >>> 0` (only for workers) until a reliable solution is found.

At least that would work for `new (class extends Int8Array {})([1, 2])`, which currently fails due to the extra object in the prototype chain.

It's a bit strange, though, that test_objectgrips-20.js passes for workers when removing the code from bug 1522244. But in practice it doesn't work, calling the getter throws.

Interestingly, doing
```js
return new globalThis[object.class](object.unsafeDereference()).length;
```
seems to work fine, the downside is that the data is copied.

So in fact I think that this is a JS problem, all steps performed by [`get %TypedArray%.prototype.length`](https://tc39.github.io/ecma262/#sec-get-%typedarray%.prototype.length) should also happen in [`TypedArray(typedArray)`](https://tc39.github.io/ecma262/#sec-typedarray-typedarray), so it doesn't make sense that the former throws and the latter does not.

It doesn't help that the error is an Opaque object, so I can't read the message. And probably the code runs in an invisibleToDebugger compartment, I can't debug it. I guess I should debug the C++ instead...

(In reply to Brian Hackett (:bhackett) from comment #4)
> philosophically I feel that calling .length on the typed array in the debuggee is the right thing to do.

I disagree (bug 1406182). If you have `var arr = Object.setPrototypeOf(new Uint8Array([1,2,3]), null)`, there is no `arr.length`, but you can still use `arr[0]`, `arr[1]`, etc. to access the data. So the devtools shouldn't hide this data.

That said, if the [[ArrayLength]] cannot be easily accessed in workers, then using `object.proto.proto.getOwnPropertyDescriptor("length").get` instead doesn't make sense because it makes various unreliable assumptions. So I would agree to change it to the simpler `DevToolsUtils.getProperty(object, "length") >>> 0` (only for workers) until a reliable solution is found.

At least that would work for `new (class extends Int8Array {})([1, 2])`, which currently fails due to the extra object in the prototype chain.