Brandon Benvie [:benvie] Reporter
	Description • 11 years ago

The %TypedArray% constructor is a function that isn't exposed globally, but all ArrayBufferView constructors inherit from it such that:

> Uint8Array.__proto__ === %TypedArray%

This allows static functions (such as `%TypedArray%.from` to be only exist in one spot (on %TypedArray%) and have it work for all the ArrayBufferView types.

%TypedArray% is itself actually a callable constructor, but it's set up in such a way that it only is callable by an initializing subclass via super, so this shouldn't be observable from JS until classes and super are implemented. For now it can simply throw a TypeError if called.

Along with constructor side inheritance, there is also prototype side inheritance such that:

> Uint8Array.prototype.__proto__ === %TypedArray%.prototype

See ES6 spec (July 2013 revision) section 15.13.6.1 and 15.13.6.4.

	Jeff Walden [:Waldo] Assignee
	Comment 2 • 10 years ago

This passes all shell jstests and jit-tests.

My guess is there are a few tests in the tree that expect the typed array functions to live on the prototypes that'll need fixing, so that's one bit of work to do.  Probably not a huge amount, tho.

The one big remaining issue is making xrays work with this nonsense, seeing as xray code more or less manually builds up its own remodeling of the builtin JS stuff.  I expect typed arrays will *pass* just fine as xrays right now, but none of the methods will be available on them.  To be picked up Monday or so...

	Jeff Walden [:Waldo] Assignee
	Comment 3 • 10 years ago

I'm fairly sure this is a complete implementation.  A try-push of largely this patch, with one or two things different in it, passed basically everywhere, so it's probably good.

https://tbpl.mozilla.org/?tree=Try&rev=50e73a0ccf56

As the spec reads right now, "" + Uint8Array.prototype or "" + %TypedArray%.prototype throws a TypeError, which seems rather unfriendly.  To some extent we can't even implement that, because of our looking at JSClass::name.  So I punted by keeping the same behavior for the current prototypes and using ??? for %TypedArray%.prototype.  (??? comes from what should happen for Object.prototype.toString called on a value whose @@toStringTag is a non-string, non-undefined value.  Not right, but closer to a right sense.)  I'm rather surprised that they want Object.prototype.toString to be able to throw, but eh.  I kind of doubt it'll stick for the typed array prototypes, and a spec change for them at least will be necessary, but who knows.  Something to find out when we actually have a @@toStringTag landed, I guess.

Faster review would be appreciated due to this touching so much of TypedArrayObject.*, but I doubt we want anyone other than bholley reviewing the xray bits, so there's at least some slack on that til he returns from PTO.  Might be nice to have it all reviewed *except* the xray bits by that time, tho, and depending on the quantity of requested changes a bigger head start might help with that.

	Till Schneidereit [:till]
	Comment 4 • 10 years ago

Comment on attachment 8479609 [details] [diff] [review]
Patch ready to go

Review of attachment 8479609 [details] [diff] [review]:
-----------------------------------------------------------------

This turned out pretty nicely! Only nits, and not many of them, so r=me.

::: js/src/tests/js1_8_5/extensions/dataview.js
@@ +1569,5 @@
> +    // Technically the spec requires this throw a TypeError -- right now.  It's
> +    // not clear this is desirable (and even less clearly desirable for the
> +    // typed array prototypes, above).  If ES6 changes or we implement
> +    // @@toStringTag (and can see how these semantics fare in practice), we'll
> +    // change this accordingly.

Is a bug for this on file at bugs.ecmascript.org? Would be nice.

::: js/src/tests/js1_8_5/extensions/typedarray.js
@@ +573,4 @@
>      check(function () Object.getPrototypeOf(view) == Object.getPrototypeOf(simple));
>      check(function () Object.getPrototypeOf(view) == Int8Array.prototype);
>  
> +    // (most) named properties are defined on %TypedArray%.prototype

Uber-nit: since this is a full sentence, please start uppercase and add a dot at the end.

::: js/src/vm/GlobalObject.h
@@ +91,5 @@
>      static const unsigned ARRAY_ITERATOR_PROTO  = FROM_BUFFER_UINT8CLAMPED + 1;
>      static const unsigned STRING_ITERATOR_PROTO  = ARRAY_ITERATOR_PROTO + 1;
> +    static const unsigned TYPEDARRAY_CTOR = STRING_ITERATOR_PROTO + 1;
> +    static const unsigned TYPEDARRAY_PROTO = TYPEDARRAY_CTOR + 1;
> +    static const unsigned LEGACY_GENERATOR_OBJECT_PROTO = TYPEDARRAY_PROTO + 1;

Not that it matters much, but I think these two should go above ARRAY_ITERATOR_PROTO or after all the generator/iterator stuff.

@@ +439,3 @@
>    private:
> +    static bool
> +    ensureTypedArray(JSContext *cx, Handle<GlobalObject*> global);

Can you call this "ensureTypedArrayConstructor"? It's not particularly ambiguous without that, but seems weird to me. And the proposed name would match the generic "ensureConstructor".

::: js/src/vm/TypedArrayObject.cpp
@@ +871,5 @@
>              return true;
>          }
>  
> +        // Copy |source| in case it overlaps the target elements being set.
> +        uint8_t *srcbuf = target->zone()->pod_malloc<uint8_t>(byteLength);

Would be nice to only copy the overlapping region. OTOH, that'd probably complicate things quite a bit, so probably not worth it as long as this all doesn't show up in any profiles.

@@ +1013,5 @@
> + * We could restructure all this code to make this nicer, but since ICS isn't
> + * going to be around forever (and since this bug is fixed with the newer GCC
> + * versions we use on JB and KK), the workaround here is designed for ease of
> + * removal. When you stop seeing ICS Emulator builds on TBPL, remove these 3
> + * JSNatives and insert the templated callee directly into the JS_PSG below.

Would sure be nice if we had a process for this. Something like "upon removing support for a specific compiler, check for a bug with the naming scheme [bullet-proof, easy to find naming scheme] and go through the blocking bugs indicating all the band-aids that can now be removed." You know, as an item on that checklist that surely is used on such occasions.

(Also, as workarounds go, this one's not so bad.)

@@ +1062,3 @@
>  };
> +
> +const JSPropertySpec* const js::TypedArrayPrototypeProperties = TypedArrayObject::protoAccessors;

Perhaps add comment explaining what this is for?

@@ +1070,5 @@
> +    MOZ_ASSERT(is(args.thisv()));
> +
> +    Rooted<TypedArrayObject*> tarray(cx, &args.thisv().toObject().as<TypedArrayObject>());
> +
> +    // these are the default values

Nit: full sentence, so proper capitalization and dot at the end, please. (I know, preexisting.)

@@ +1194,5 @@
> +    MOZ_ASSERT(is(args.thisv()));
> +
> +    Rooted<TypedArrayObject*> target(cx, &args.thisv().toObject().as<TypedArrayObject>());
> +
> +    // first arg must be either a typed array or a JS array

Preexisting nit: source doesn't have to be a JS array, but an array-like. Also, full sentence and all that.

@@ +1202,5 @@
> +    }
> +
> +    int32_t offset = 0;
> +    if (args.length() > 1) {
> +        if (!ToInt32(cx, args[1], &offset))

At some point we should fix out implementation to not restrict the typed array length to uint32.

@@ +1206,5 @@
> +        if (!ToInt32(cx, args[1], &offset))
> +            return false;
> +
> +        if (offset < 0 || uint32_t(offset) > target->length()) {
> +            // the given offset is bogus

Whole sentence.

@@ +1228,5 @@
> +        uint32_t len;
> +        if (!GetLengthProperty(cx, arg0, &len))
> +            return false;
> +
> +        if (uint32_t(offset) > target->length() || len > target->length() - offset) {

The first part is covered above, so can be removed here.

@@ +1350,3 @@
>  };
> +
> +const JSFunctionSpec* const js::TypedArrayPrototypeFunctions = TypedArrayObject::protoFunctions;

Same here: add a comment explaining what this is for, perhaps.

@@ +1352,5 @@
> +const JSFunctionSpec* const js::TypedArrayPrototypeFunctions = TypedArrayObject::protoFunctions;
> +
> +/* static */ const JSFunctionSpec
> +TypedArrayObject::staticFunctions[] = {
> +    // Coming soon...

How ominous.

::: js/xpconnect/wrappers/XrayWrapper.cpp
@@ +865,5 @@
> +    // Grab the JSClass. We require all Xrayable classes to have a ClassSpec.
> +    const js::Class *clasp = js::GetObjectClass(target);
> +    MOZ_ASSERT(clasp->spec.defined());
> +
> +    // Typed arrays' prototype chains don't proceed according to normal form.

I think "don't proceed according to normal form" is putting it a bit strongly. While unprecedented for builtins, it's absolutely common for content code. Perhaps just "Typed arrays' prototype chains have an additional %TypedArray%.prototype object interspersed between <typed array class>.prototype and Object.prototype"?

@@ +1128,5 @@
>      // Grab the JSClass. We require all Xrayable classes to have a ClassSpec.
>      const js::Class *clasp = js::GetObjectClass(target);
>      MOZ_ASSERT(clasp->spec.defined());
> +
> +    // Typed arrays' prototype chains are weird.  Replicate the effect of the

s/weird/different/? (Yes, mostly joking.)
"Replicate the tactic"?

	Jeff Walden [:Waldo] Assignee
	Comment 5 • 10 years ago

No major changes here, tho I did tweak the JSClass::name for the prototype classes to be Uint8ArrayPrototype as they are now (not Uint8Array as I semi-thought they currently were).  No changes at all to the Xray aspects of this that are the only portion still needing review.

Regarding some of the comment comments, while I fixed the ones noted, basically every other nearby comment is wrong in the same way.  I didn't worry about it because patch size and scope creep, but more importantly because I want to self-host basically all these algorithms in very short order, which entails rewriting them with step-by-step comments, so doing much to the existing ones is lipstick on a pig.

No bug filed yet on "" + Uint8Array.prototype throwing yet.  I'll do it once this patch lands.

	Bobby Holley (:bholley)
	Comment 6 • 10 years ago

Comment on attachment 8480200 [details] [diff] [review]
Updated to comments

Review of attachment 8480200 [details] [diff] [review]:
-----------------------------------------------------------------

Per IRC discussion, I think we should try harder to use the generic machinery for the Xray stuff, and should make these "dependent" classes.

	Jeff Walden [:Waldo] Assignee
	Comment 7 • 10 years ago

Bug 1054882 completely destroyed this patch.  I've spent the last six hours today digging out from under the rubble and am still not there yet.  I wouldn't be surprised if this eats up much/most of tomorrow as well.

Hopefully the various followup bugs for that will be small fixes that won't make rebasing too painful.  I'm not particularly optimistic.

Xray nonsense still needs to be written, probably as a patch underneath this, then adjusting the rebased patch to work atop that.  Pretty sure xrays are going to be responsible for 80% of the time I'll have invested in this patch by the time it lands -- partly because of xrays delaying things long enough for bug 1054882 to destroy this, but even ignoring that, it'd still be more than half the time overall.

	Lars T Hansen [:lth]
	Comment 8 • 10 years ago

(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #7)
> Bug 1054882 completely destroyed this patch.

Sorry!

I don't know if you'll find it helpful to share more or less code with SharedArrayBuffer / SharedTypedArray.  If you think you'll find find it helpful to share more, by all means do propose changes to SharedTypedArray that makes sharing code possible - its current design is the simplest that was also useful, not the result of some protracted negotiation.

	Bobby Holley (:bholley)
	Comment 9 • 10 years ago

(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #7)
> Pretty sure xrays
> are going to be responsible for 80% of the time I'll have invested in this
> patch by the time it lands

Welcome to my, bz's, and peterv's world. It's annoying to deal with, but we don't really have a choice.

	Jeff Walden [:Waldo] Assignee
	Comment 10 • 10 years ago

It's unclear whether this could have been split up or not, given the mess that is Error classing right now.  Too late to do it particularly sensibly once I finished the patch, in any event.

	Jeff Walden [:Waldo] Assignee
	Comment 11 • 10 years ago

And the patch.  I didn't change the shared typed array hierarchy in similar fashion.  This is messily big enough as it is, without taking on extra work for non-shipping code.  And the rebases of this patch are a killer.  Get it done, get it in, clean that up later if they end up specifying it that way.

	Jeff Walden [:Waldo] Assignee
	Comment 12 • 10 years ago

(In reply to Lars T Hansen [:lth] from comment #8)
> (In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #7)
> > Bug 1054882 completely destroyed this patch.
> 
> Sorry!

The sympathy is appreciated, but truly, an apology isn't necessary.  :-)  Comes with the terrain of working on shared code being aggressively modified.  Just usually not quite to this level of destruction.

In any event, I was trying my best to do the same thing to you, I just had too many things distracting me to finish this sooner.  ;-)  This was far, far more venting than serious complaint.

> I don't know if you'll find it helpful to share more or less code with
> SharedArrayBuffer / SharedTypedArray.  If you think you'll find find it
> helpful to share more, by all means do propose changes to SharedTypedArray
> that makes sharing code possible - its current design is the simplest that
> was also useful, not the result of some protracted negotiation.

Mostly I left it as-is as much as possible.  This is big enough already without scope-creeping into making adjustments experimental features, in advance of discussion of those changes.  And my todo list is big enough already.  :-)

(In reply to Bobby Holley (:bholley) from comment #9)
> It's annoying to deal with, but we don't really have a choice.

I'm still very much unconvinced there's not a better way to do this, that doesn't require deep-reaching changes to code outside the JS engine every time a simple standard library adjustment occurs.  My tolerance for XPConnect's incestuousness with the JS engine is much, much lower than yours.  Doesn't mean I've come up with an alternative yet, but I'm nowhere near giving up hope yet.

	Till Schneidereit [:till]
	Comment 14 • 10 years ago

Comment on attachment 8492005 [details] [diff] [review]
With one last qref

Review of attachment 8492005 [details] [diff] [review]:
-----------------------------------------------------------------

In some respects this is even nicer than the previous version, I think. r=me with GenericArray renamed, as requested below.

::: js/src/tests/ecma_6/TypedArray/prototype-constructor-identity.js
@@ +1,3 @@
> +/*
> + * Any copyright is dedicated to the Public Domain.
> + * http://creativecommons.org/licenses/publicdomain/

Apparently, https://creativecommons.org/publicdomain/zero/1.0/ is what should be used now.

::: js/src/vm/SharedTypedArrayObject.cpp
@@ +562,5 @@
> +// and each function only works on the corresponding kind of shared typed array
> +// (enforced by SharedTypedArrayObjectTemplate<T>::is in these methods).
> +//
> +// It may be worth changing the shared typed array spec to use a similar
> +// %SharedTypedArray% structure, to similarly avoid duplication.

I'm almost entirely convinced that lth plans on changing the spec to that effect, so you might as well put this a little more strongly.

::: js/src/vm/TypedArrayCommon.h
@@ +161,3 @@
>  {
> +    typedef typename SpecificArray::ElementType T;
> +    typedef typename SpecificArray::GenericArray GenericArray;

I don't think this is a good name. See comment below for why.

@@ +258,5 @@
> +                         uint32_t len, uint32_t offset = 0)
> +    {
> +        MOZ_ASSERT(target->type() == SpecificArray::ArrayTypeID(),
> +                   "target type and NativeType must match");
> +        MOZ_ASSERT(!source->is<GenericArray>(),

"GenericArray" is really confusing here. It sounds like the opposite of a type-specific array, which it obviously isn't. Maybe "AnyTypedArray" would be a better name?

@@ +276,5 @@
> +            const Value *srcValues = source->getDenseElements();
> +            for (; i < bound; i++) {
> +                if (!canConvertInfallibly(srcValues[i]))
> +                    break;
> +                dest[i] = infallibleValueToNative(srcValues[i]);

Not directly related to this patch, but I wonder if we couldn't have an even faster path here that uses TI to make sure that all elements can be infallibly converted - or don't even need to be converted.

This'd be really nice because of how common it is to initialize a typed array from an untyped one.

@@ +613,5 @@
>  
> +        // Technically |from + count| and |to + count| can't overflow, because
> +        // buffer contents are limited to INT32_MAX length.  But eventually
> +        // we're going to lift this restriction, and the extra checking cost is
> +        // negligible, so just handle it anyway. 

Nit: whitespace

::: js/src/vm/TypedArrayObject.cpp
@@ +241,5 @@
>          }
>  
> +        RootedFunction fun(cx);
> +        fun =
> +            NewFunction(cx, NullPtr(),

Nit: remove \n before NewFunction. The longest argument should still fit into 99 cols

::: js/src/vm/TypedArrayObject.h
@@ +96,5 @@
>      static const Class classes[Scalar::TypeMax];
>      static const Class protoClasses[Scalar::TypeMax];
> +    static const Class sharedTypedArrayPrototypeClass;
> +
> +    static const Class * classForType(Scalar::Type type) {

Nit: no space between * and function name (surprisingly, this is the first time Class * is used as a return value. I don't see why the usual style shouldn't hold for that, though.)

@@ +101,5 @@
> +        MOZ_ASSERT(type < Scalar::TypeMax);
> +        return &classes[type];
> +    }
> +
> +    static const Class * protoClassForType(Scalar::Type type) {

Same here

	Bobby Holley (:bholley)
	Comment 15 • 10 years ago

Comment on attachment 8491997 [details] [diff] [review]
Morph the dependent-class system to store a parent key directly, change Error to use multiple classes

Review of attachment 8491997 [details] [diff] [review]:
-----------------------------------------------------------------

r=bholley modulo that stuff. Thanks a lot for doing this.

::: js/public/Class.h
@@ +314,5 @@
> +        static_assert(JSProto_Null == 0, "zeroed key must be null");
> +        return JSProtoKey(flags & ParentKeyMask);
> +    }
> +
> +    bool shouldDefineConstructor() const {

Hm, what is this about? It doesn't seem to be used anywhere in the patch. Is that intentional?

::: js/src/jsfriendapi.h
@@ +632,4 @@
>  ProtoKeyToClass(JSProtoKey key);
>  
>  // Returns true if the standard class identified by |key| inherits from
> +// another standard class along its proto chain.

maybe "another standard class (other than Object)"

::: js/src/vm/ErrorObject.h
@@ +71,5 @@
> +        return &classes[type];
> +    }
> +
> +    static bool isErrorClass(const Class *clasp) {
> +        return &classes[0] <= clasp && clasp < &classes[JSEXN_LIMIT];

&classes[JSEXN_LIMIT] is a little sketchy, though fine since you never dereference it. Maybe it would be better to do:

clasp >= classes && clasp - classes < ArrayLength(classes)

::: js/xpconnect/wrappers/XrayWrapper.cpp
@@ +422,5 @@
>      }
>  
> +    // Compute the property name we're looking for. Indexed array properties
> +    // are handled above. We'll handle well-known symbols when we start
> +    // supporting Symbol.iterator in bug 918828.

Presumably you also need to remove the now-duplicated code later in this function.

@@ +697,1 @@
>      // Add the 'constructor' property.

Do we want to check the shouldDefineConstructor stuff here and in resolveOwnProperty?

	Bobby Holley (:bholley)
	Comment 16 • 10 years ago

Comment on attachment 8492005 [details] [diff] [review]
With one last qref

Review of attachment 8492005 [details] [diff] [review]:
-----------------------------------------------------------------

\o/

::: js/src/vm/TypedArrayObject.cpp
@@ +797,5 @@
> +        TypedArrayObject::staticFunctions,
> +        TypedArrayObject::protoFunctions,
> +        TypedArrayObject::protoAccessors,
> +        nullptr,
> +        ClassSpec::DontDefineConstructor

Oh I see, it's here. Nevermind on that comment from the other review then.

	Jeff Walden [:Waldo] Assignee
	Comment 17 • 10 years ago

(In reply to Bobby Holley (:bholley) from comment #15)
> > +    static bool isErrorClass(const Class *clasp) {
> > +        return &classes[0] <= clasp && clasp < &classes[JSEXN_LIMIT];
> 
> &classes[JSEXN_LIMIT] is a little sketchy, though fine since you never
> dereference it.

Fair point on manually computing the end element.  I'll do this:

  &classes[0] <= clasp && clasp < &classes[0] + ArrayLength(classes)

> clasp >= classes && clasp - classes < ArrayLength(classes)

It's undefined behavior to subtract pointers to objects not in (or one past) the same array, C++11 [expr.add]p6 last sentence, which would make |clasp - classes| exhibit undefined behavior when called on non-Errors.

> Presumably you also need to remove the now-duplicated code later in this
> function.

Hm, actually I meant to not touch it at all.  Maybe a rebasing mistake or so.

> Do we want to check the shouldDefineConstructor stuff here and in
> resolveOwnProperty?

Object.getPrototypeOf(Uint8Array.prototype).constructor exists.  I can't think of a good reason to go out of the way to eliminate it here.

	Till Schneidereit [:till]
	Comment 18 • 10 years ago

Comment on attachment 8491997 [details] [diff] [review]
Morph the dependent-class system to store a parent key directly, change Error to use multiple classes

Review of attachment 8491997 [details] [diff] [review]:
-----------------------------------------------------------------

Yes, absolutely.

	Jeff Walden [:Waldo] Assignee
	Comment 19 • 10 years ago

Landed:

https://hg.mozilla.org/integration/mozilla-inbound/rev/b0eda4f5c21e
https://hg.mozilla.org/integration/mozilla-inbound/rev/bcf65e0b6da6

...and a followup for an ASAN failure that sadly wasn't caught by normal tests, and that I don't remember seeing in the last try-push I did.

https://hg.mozilla.org/integration/mozilla-inbound/rev/168e812e4e82

The issue was when doing a set() with overlapping memory, between different-element-type arrays, the temporary space we'd copy source elements into was source length * target-element-size, when it should have been source length * source-element-size.  Simple fix, included a test that fails with the normal allocator without need for ASAN.

Hopefully this code won't last too long and we can self-host it in super-short order, to eliminate such mistakes in the future.

	Steve Fink [:sfink] [:s:]
	Comment 20 • 10 years ago

(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #17)
> (In reply to Bobby Holley (:bholley) from comment #15)
> > > +    static bool isErrorClass(const Class *clasp) {
> > > +        return &classes[0] <= clasp && clasp < &classes[JSEXN_LIMIT];
> > 
> > &classes[JSEXN_LIMIT] is a little sketchy, though fine since you never
> > dereference it.

Boo. Nothing sketchy about &classes[JSEXN_LIMIT]. And it reads better.

> Fair point on manually computing the end element.  I'll do this:
> 
>   &classes[0] <= clasp && clasp < &classes[0] + ArrayLength(classes)

Ok, fine, depending on JSEXN_LIMIT isn't 100% safe. Personally, I'd still do

  static_assert(JSEXN_LIMIT == ArrayLength(classes));
  return &classes[0] <= clasp && clasp < &classes[JSEXN_LIMIT];

because &classes[ArrayLength(classes)] is kinda ugly, though it's not *that* bad.

But never mind me, just bikeshedding.

	Ryan VanderMeulen [:RyanVM]
	Comment 21 • 10 years ago

https://hg.mozilla.org/mozilla-central/rev/b0eda4f5c21e
https://hg.mozilla.org/mozilla-central/rev/bcf65e0b6da6
https://hg.mozilla.org/mozilla-central/rev/168e812e4e82

	Jeff Walden [:Waldo] Assignee
	Comment 22 • 10 years ago

I updated https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypedArray a bit to not be inconsistent with the introduction of %TypedArray%.  There's doubtless more to be done here, beyond that, not least mentioning it in "New in" documentation.

	Florian Scholz (Open Web Docs)
	Comment 23 • 10 years ago

Thanks a lot Waldo! These reviews are very much appreciated!

> There's doubtless more to be done here, beyond that, not
> least mentioning it in "New in" documentation.

I added a note to https://developer.mozilla.org/en-US/Firefox/Releases/35#JavaScript
What would you add or update in addition to the current documentation?

	Jeff Walden [:Waldo] Assignee
	Comment 24 • 10 years ago

I made a few more tweaks to the release notes bits.  The big part is that there are *two* ways %TypedArray% plays into inheritance: for each individual typed array constructor, and then for each individual typed array prototype via %TypedArray%.prototype.  The former is the less interesting part, because we haven't implemented Uint8Array.from or any of the "static" functions yet.  The latter is more important, because there are copyWithin/set/subarray methods that moved as a result of that addition.

Beyond those tweaks, I don't have anything to add to that bit of change.

	Florian Scholz (Open Web Docs)
	Comment 25 • 10 years ago

Great, thanks for explaining that!

	Jeff Walden [:Waldo] Assignee
	Comment 26 • 10 years ago

Blogged about this briefly, too:

http://whereswalden.com/2014/09/26/minor-changes-are-coming-to-typed-arrays-in-firefox-and-es6/