Re: [blink-dev] Intent to Ship: Resizable ArrayBuffer and growable SharedArrayBuffer

[Daniel Bratell]

LGTM3.

Also happy to see the technical term "super slow" get some use. :)

/Daniel

On 2022-11-23 07:58, Mike West wrote:

LGTM2.

-mike


On Wed, Nov 23, 2022 at 4:06 AM Yoav Weiss  wrote:



On Tue, Nov 22, 2022 at 6:54 PM Marja Hölttä 
wrote:

Thanks for the LGTM!

Re: "wouldn't the userland name win" - typically the situation
is more complicated than that. E.g., one part of the user code
marks objects by adding a property 'foo' and another part
checks whether my_object.foo != undefined. If we now add 'foo'
somewhere in the prototype chain, this logic breaks: it will
think that an unmarked object is actually marked. -> Adding
properties like this can break user code in arbitrary ways.


Yeah, makes sense!



On Tue, Nov 22, 2022 at 2:37 PM Yoav Weiss
 wrote:

LGTM1

On Tue, Nov 22, 2022 at 2:14 PM Marja Hölttä
 wrote:

Other engines: At least Apple has started implementing
this feature, but this is a big feature, so it'll take
some time. We've pushed for test262 coverage, so
hopefully getting the feature into production will
take less time for them than it did for us.

Web sites can feature-detect this feature, e.g., by
checking the existence of ArrayBuffer.prototype.resize
and SharedArrayBuffer.prototype.grow.

The potential backwards compatibility problem is the
names 'resize' and 'grow' colliding. This can always
happen when adding new methods, although the risk here
is lower than w/ adding methods to Array.prototype.
Based on the past, we won't find out about such
problems until we ship.


In case of such a collision, wouldn't the userland name win?
I guess we could run e.g. ClusterTelemetry with that
change and see if the usecounters are hit (or something
similar), just to be extra cautious.



On Mon, Nov 21, 2022 at 1:56 PM Yoav Weiss
 wrote:



On Fri, Nov 18, 2022 at 1:59 PM Marja Hölttä
 wrote:


Contact emails

ma...@chromium.org, s...@chromium.org


Explainer


https://github.com/tc39/proposal-resizablearraybuffer/blob/master/README.md


Specification

https://tc39.es/proposal-resizablearraybuffer/


Summary

Extend the ArrayBuffer constructors to take an
additional maximum length that allows in-place
growth and shrinking of buffers. Similarly,
SharedArrayBuffer is extended to take an
additional maximum length that allows in-place
growth.



Blink component

Blink>JavaScript>Language




TAG review



TAG review status

Not applicable


Risks



Interoperability and Compatibility

Interop risk exists in that resizing and
growing the backing store, as well as
reserving the initial virtual memory, are
platform and OS-dependent. To that end the
spec draft recommends implementation
guidelines:

https://tc39.es/proposal-resizablearraybuffer/#sec-maxbytelength-guidelines



/Gecko/: Positive
(https://bugzilla.mozilla.org/show_bug.cgi?id=1670026)
Assumed positive because this proposal is
Stage 3 in TC39.

/WebKit/: Positive Assumed positive because
this proposal is Stage 3 in TC39.


Do you know what their shipping plans are?
Otherwise, what's the backwards compat story? Is
there feature detection for this new capability?


/Web developers/: No signals

/Other signals/: -


Security

ArrayBuffers and TypedArrays are a leading
vector of attack. The feature has been
designed to be implementable with a fixed data
pointer to the backing store. S

Re: [blink-dev] Intent to Ship: Resizable ArrayBuffer and growable SharedArrayBuffer

[Mike West]

LGTM2.

-mike


On Wed, Nov 23, 2022 at 4:06 AM Yoav Weiss  wrote:

>
>
> On Tue, Nov 22, 2022 at 6:54 PM Marja Hölttä  wrote:
>
>> Thanks for the LGTM!
>>
>> Re: "wouldn't the userland name win" - typically the situation is more
>> complicated than that. E.g., one part of the user code marks objects by
>> adding a property 'foo' and another part checks whether my_object.foo !=
>> undefined. If we now add 'foo' somewhere in the prototype chain, this logic
>> breaks: it will think that an unmarked object is actually marked. -> Adding
>> properties like this can break user code in arbitrary ways.
>>
>
> Yeah, makes sense!
>
>
>>
>>
>> On Tue, Nov 22, 2022 at 2:37 PM Yoav Weiss 
>> wrote:
>>
>>> LGTM1
>>>
>>> On Tue, Nov 22, 2022 at 2:14 PM Marja Hölttä  wrote:
>>>
 Other engines: At least Apple has started implementing this feature,
 but this is a big feature, so it'll take some time. We've pushed for
 test262 coverage, so hopefully getting the feature into production will
 take less time for them than it did for us.

 Web sites can feature-detect this feature, e.g., by checking the
 existence of ArrayBuffer.prototype.resize and
 SharedArrayBuffer.prototype.grow.

 The potential backwards compatibility problem is the names 'resize' and
 'grow' colliding. This can always happen when adding new methods, although
 the risk here is lower than w/ adding methods to Array.prototype. Based on
 the past, we won't find out about such problems until we ship.

>>>
>>> In case of such a collision, wouldn't the userland name win?
>>> I guess we could run e.g. ClusterTelemetry with that change and see if
>>> the usecounters are hit (or something similar), just to be extra cautious.
>>>
>>>


 On Mon, Nov 21, 2022 at 1:56 PM Yoav Weiss 
 wrote:

>
>
> On Fri, Nov 18, 2022 at 1:59 PM Marja Hölttä 
> wrote:
>
>> Contact emailsma...@chromium.org, s...@chromium.org
>>
>> Explainer
>> https://github.com/tc39/proposal-resizablearraybuffer/blob/master/README.md
>>
>> Specificationhttps://tc39.es/proposal-resizablearraybuffer/
>>
>> Summary
>>
>> Extend the ArrayBuffer constructors to take an additional maximum
>> length that allows in-place growth and shrinking of buffers. Similarly,
>> SharedArrayBuffer is extended to take an additional maximum length that
>> allows in-place growth.
>>
>>
>> Blink componentBlink>JavaScript>Language
>> 
>>
>> TAG review
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Interop risk exists in that resizing and growing the backing store,
>> as well as reserving the initial virtual memory, are platform and
>> OS-dependent. To that end the spec draft recommends implementation
>> guidelines:
>> https://tc39.es/proposal-resizablearraybuffer/#sec-maxbytelength-guidelines
>>
>>
>> *Gecko*: Positive (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1670026) Assumed
>> positive because this proposal is Stage 3 in TC39.
>>
>> *WebKit*: Positive Assumed positive because this proposal is Stage 3
>> in TC39.
>>
>
> Do you know what their shipping plans are? Otherwise, what's the
> backwards compat story? Is there feature detection for this new 
> capability?
>
>
>>
>> *Web developers*: No signals
>>
>> *Other signals*: -
>>
>> Security
>>
>> ArrayBuffers and TypedArrays are a leading vector of attack. The
>> feature has been designed to be implementable with a fixed data pointer 
>> to
>> the backing store. See
>> https://github.com/tc39/proposal-resizablearraybuffer#security The
>> security review has been done by the V8 Security team.
>>
>>
>> WebView application risks
>>
>> -
>>
>>
>>
>> Debuggability
>>
>> DevTools can already debug ArrayBuffers and SharedArrayBuffers.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows,
>> Mac, Linux, Chrome OS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Tested by test262
>>
>> Flag name--harmony-rab-gsab
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=1
>>
>> Estimated milestones
>>
>> M110
>>
>>
>> Anticipated spec changes
>>
>> Included in the proposal's spec
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/4668361878274048
>>
>> This intent message was generated by Chrome Platfo

Re: [blink-dev] Intent to Ship: Resizable ArrayBuffer and growable SharedArrayBuffer

[Yoav Weiss]

On Tue, Nov 22, 2022 at 6:54 PM Marja Hölttä  wrote:

> Thanks for the LGTM!
>
> Re: "wouldn't the userland name win" - typically the situation is more
> complicated than that. E.g., one part of the user code marks objects by
> adding a property 'foo' and another part checks whether my_object.foo !=
> undefined. If we now add 'foo' somewhere in the prototype chain, this logic
> breaks: it will think that an unmarked object is actually marked. -> Adding
> properties like this can break user code in arbitrary ways.
>

Yeah, makes sense!


>
>
> On Tue, Nov 22, 2022 at 2:37 PM Yoav Weiss  wrote:
>
>> LGTM1
>>
>> On Tue, Nov 22, 2022 at 2:14 PM Marja Hölttä  wrote:
>>
>>> Other engines: At least Apple has started implementing this feature, but
>>> this is a big feature, so it'll take some time. We've pushed for test262
>>> coverage, so hopefully getting the feature into production will take less
>>> time for them than it did for us.
>>>
>>> Web sites can feature-detect this feature, e.g., by checking the
>>> existence of ArrayBuffer.prototype.resize and
>>> SharedArrayBuffer.prototype.grow.
>>>
>>> The potential backwards compatibility problem is the names 'resize' and
>>> 'grow' colliding. This can always happen when adding new methods, although
>>> the risk here is lower than w/ adding methods to Array.prototype. Based on
>>> the past, we won't find out about such problems until we ship.
>>>
>>
>> In case of such a collision, wouldn't the userland name win?
>> I guess we could run e.g. ClusterTelemetry with that change and see if
>> the usecounters are hit (or something similar), just to be extra cautious.
>>
>>
>>>
>>>
>>> On Mon, Nov 21, 2022 at 1:56 PM Yoav Weiss 
>>> wrote:
>>>


 On Fri, Nov 18, 2022 at 1:59 PM Marja Hölttä 
 wrote:

> Contact emailsma...@chromium.org, s...@chromium.org
>
> Explainer
> https://github.com/tc39/proposal-resizablearraybuffer/blob/master/README.md
>
> Specificationhttps://tc39.es/proposal-resizablearraybuffer/
>
> Summary
>
> Extend the ArrayBuffer constructors to take an additional maximum
> length that allows in-place growth and shrinking of buffers. Similarly,
> SharedArrayBuffer is extended to take an additional maximum length that
> allows in-place growth.
>
>
> Blink componentBlink>JavaScript>Language
> 
>
> TAG review
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Interop risk exists in that resizing and growing the backing store, as
> well as reserving the initial virtual memory, are platform and
> OS-dependent. To that end the spec draft recommends implementation
> guidelines:
> https://tc39.es/proposal-resizablearraybuffer/#sec-maxbytelength-guidelines
>
>
> *Gecko*: Positive (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1670026) Assumed
> positive because this proposal is Stage 3 in TC39.
>
> *WebKit*: Positive Assumed positive because this proposal is Stage 3
> in TC39.
>

 Do you know what their shipping plans are? Otherwise, what's the
 backwards compat story? Is there feature detection for this new capability?


>
> *Web developers*: No signals
>
> *Other signals*: -
>
> Security
>
> ArrayBuffers and TypedArrays are a leading vector of attack. The
> feature has been designed to be implementable with a fixed data pointer to
> the backing store. See
> https://github.com/tc39/proposal-resizablearraybuffer#security The
> security review has been done by the V8 Security team.
>
>
> WebView application risks
>
> -
>
>
>
> Debuggability
>
> DevTools can already debug ArrayBuffers and SharedArrayBuffers.
>
>
> Will this feature be supported on all six Blink platforms (Windows,
> Mac, Linux, Chrome OS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?Tested by test262
>
> Flag name--harmony-rab-gsab
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=1
>
> Estimated milestones
>
> M110
>
>
> Anticipated spec changes
>
> Included in the proposal's spec
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/4668361878274048
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
>
>
> Google Germany GmbH
>
> Erika-Mann-Straße 33
>
> 80636 München
>
> Geschäftsführer: Paul Manicle, Liana Sebastian.
>
> Registergerich

Re: [blink-dev] Intent to Ship: Resizable ArrayBuffer and growable SharedArrayBuffer

[Marja Hölttä]

Thanks for the LGTM!

Re: "wouldn't the userland name win" - typically the situation is more
complicated than that. E.g., one part of the user code marks objects by
adding a property 'foo' and another part checks whether my_object.foo !=
undefined. If we now add 'foo' somewhere in the prototype chain, this logic
breaks: it will think that an unmarked object is actually marked. -> Adding
properties like this can break user code in arbitrary ways.


On Tue, Nov 22, 2022 at 2:37 PM Yoav Weiss  wrote:

> LGTM1
>
> On Tue, Nov 22, 2022 at 2:14 PM Marja Hölttä  wrote:
>
>> Other engines: At least Apple has started implementing this feature, but
>> this is a big feature, so it'll take some time. We've pushed for test262
>> coverage, so hopefully getting the feature into production will take less
>> time for them than it did for us.
>>
>> Web sites can feature-detect this feature, e.g., by checking the
>> existence of ArrayBuffer.prototype.resize and
>> SharedArrayBuffer.prototype.grow.
>>
>> The potential backwards compatibility problem is the names 'resize' and
>> 'grow' colliding. This can always happen when adding new methods, although
>> the risk here is lower than w/ adding methods to Array.prototype. Based on
>> the past, we won't find out about such problems until we ship.
>>
>
> In case of such a collision, wouldn't the userland name win?
> I guess we could run e.g. ClusterTelemetry with that change and see if the
> usecounters are hit (or something similar), just to be extra cautious.
>
>
>>
>>
>> On Mon, Nov 21, 2022 at 1:56 PM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Fri, Nov 18, 2022 at 1:59 PM Marja Hölttä  wrote:
>>>
 Contact emailsma...@chromium.org, s...@chromium.org

 Explainer
 https://github.com/tc39/proposal-resizablearraybuffer/blob/master/README.md

 Specificationhttps://tc39.es/proposal-resizablearraybuffer/

 Summary

 Extend the ArrayBuffer constructors to take an additional maximum
 length that allows in-place growth and shrinking of buffers. Similarly,
 SharedArrayBuffer is extended to take an additional maximum length that
 allows in-place growth.


 Blink componentBlink>JavaScript>Language
 

 TAG review

 TAG review statusNot applicable

 Risks


 Interoperability and Compatibility

 Interop risk exists in that resizing and growing the backing store, as
 well as reserving the initial virtual memory, are platform and
 OS-dependent. To that end the spec draft recommends implementation
 guidelines:
 https://tc39.es/proposal-resizablearraybuffer/#sec-maxbytelength-guidelines


 *Gecko*: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1670026)
 Assumed positive because this proposal is Stage 3 in TC39.

 *WebKit*: Positive Assumed positive because this proposal is Stage 3
 in TC39.

>>>
>>> Do you know what their shipping plans are? Otherwise, what's the
>>> backwards compat story? Is there feature detection for this new capability?
>>>
>>>

 *Web developers*: No signals

 *Other signals*: -

 Security

 ArrayBuffers and TypedArrays are a leading vector of attack. The
 feature has been designed to be implementable with a fixed data pointer to
 the backing store. See
 https://github.com/tc39/proposal-resizablearraybuffer#security The
 security review has been done by the V8 Security team.


 WebView application risks

 -



 Debuggability

 DevTools can already debug ArrayBuffers and SharedArrayBuffers.


 Will this feature be supported on all six Blink platforms (Windows,
 Mac, Linux, Chrome OS, Android, and Android WebView)?Yes

 Is this feature fully tested by web-platform-tests
 
 ?Tested by test262

 Flag name--harmony-rab-gsab

 Requires code in //chrome?False

 Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=1

 Estimated milestones

 M110


 Anticipated spec changes

 Included in the proposal's spec


 Link to entry on the Chrome Platform Status
 https://chromestatus.com/feature/4668361878274048

 This intent message was generated by Chrome Platform Status
 .

 --


 Google Germany GmbH

 Erika-Mann-Straße 33

 80636 München

 Geschäftsführer: Paul Manicle, Liana Sebastian.

 Registergericht und -nummer: Hamburg, HRB 86891

 Sitz der Gesellschaft: Hamburg

 Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise
 erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes
 weiter, löschen Sie alle

Re: [blink-dev] Intent to Ship: Resizable ArrayBuffer and growable SharedArrayBuffer

[Yoav Weiss]

LGTM1

On Tue, Nov 22, 2022 at 2:14 PM Marja Hölttä  wrote:

> Other engines: At least Apple has started implementing this feature, but
> this is a big feature, so it'll take some time. We've pushed for test262
> coverage, so hopefully getting the feature into production will take less
> time for them than it did for us.
>
> Web sites can feature-detect this feature, e.g., by checking the existence
> of ArrayBuffer.prototype.resize and SharedArrayBuffer.prototype.grow.
>
> The potential backwards compatibility problem is the names 'resize' and
> 'grow' colliding. This can always happen when adding new methods, although
> the risk here is lower than w/ adding methods to Array.prototype. Based on
> the past, we won't find out about such problems until we ship.
>

In case of such a collision, wouldn't the userland name win?
I guess we could run e.g. ClusterTelemetry with that change and see if the
usecounters are hit (or something similar), just to be extra cautious.


>
>
> On Mon, Nov 21, 2022 at 1:56 PM Yoav Weiss  wrote:
>
>>
>>
>> On Fri, Nov 18, 2022 at 1:59 PM Marja Hölttä  wrote:
>>
>>> Contact emailsma...@chromium.org, s...@chromium.org
>>>
>>> Explainer
>>> https://github.com/tc39/proposal-resizablearraybuffer/blob/master/README.md
>>>
>>> Specificationhttps://tc39.es/proposal-resizablearraybuffer/
>>>
>>> Summary
>>>
>>> Extend the ArrayBuffer constructors to take an additional maximum length
>>> that allows in-place growth and shrinking of buffers. Similarly,
>>> SharedArrayBuffer is extended to take an additional maximum length that
>>> allows in-place growth.
>>>
>>>
>>> Blink componentBlink>JavaScript>Language
>>> 
>>>
>>> TAG review
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Interop risk exists in that resizing and growing the backing store, as
>>> well as reserving the initial virtual memory, are platform and
>>> OS-dependent. To that end the spec draft recommends implementation
>>> guidelines:
>>> https://tc39.es/proposal-resizablearraybuffer/#sec-maxbytelength-guidelines
>>>
>>>
>>> *Gecko*: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1670026)
>>> Assumed positive because this proposal is Stage 3 in TC39.
>>>
>>> *WebKit*: Positive Assumed positive because this proposal is Stage 3 in
>>> TC39.
>>>
>>
>> Do you know what their shipping plans are? Otherwise, what's the
>> backwards compat story? Is there feature detection for this new capability?
>>
>>
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*: -
>>>
>>> Security
>>>
>>> ArrayBuffers and TypedArrays are a leading vector of attack. The feature
>>> has been designed to be implementable with a fixed data pointer to the
>>> backing store. See
>>> https://github.com/tc39/proposal-resizablearraybuffer#security The
>>> security review has been done by the V8 Security team.
>>>
>>>
>>> WebView application risks
>>>
>>> -
>>>
>>>
>>>
>>> Debuggability
>>>
>>> DevTools can already debug ArrayBuffers and SharedArrayBuffers.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Tested by test262
>>>
>>> Flag name--harmony-rab-gsab
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=1
>>>
>>> Estimated milestones
>>>
>>> M110
>>>
>>>
>>> Anticipated spec changes
>>>
>>> Included in the proposal's spec
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/4668361878274048
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>>
>>> --
>>>
>>>
>>> Google Germany GmbH
>>>
>>> Erika-Mann-Straße 33
>>>
>>> 80636 München
>>>
>>> Geschäftsführer: Paul Manicle, Liana Sebastian.
>>>
>>> Registergericht und -nummer: Hamburg, HRB 86891
>>>
>>> Sitz der Gesellschaft: Hamburg
>>>
>>> Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten
>>> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
>>> löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen,
>>> dass die E-Mail an die falsche Person gesendet wurde.
>>>
>>>
>>>
>>> This e-mail is confidential. If you received this communication by
>>> mistake, please don't forward it to anyone else, please erase all copies
>>> and attachments, and please let me know that it has gone to the wrong
>>> person.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://gro

Re: [blink-dev] Intent to Ship: Resizable ArrayBuffer and growable SharedArrayBuffer

[Marja Hölttä]

Other engines: At least Apple has started implementing this feature, but
this is a big feature, so it'll take some time. We've pushed for test262
coverage, so hopefully getting the feature into production will take less
time for them than it did for us.

Web sites can feature-detect this feature, e.g., by checking the existence
of ArrayBuffer.prototype.resize and SharedArrayBuffer.prototype.grow.

The potential backwards compatibility problem is the names 'resize' and
'grow' colliding. This can always happen when adding new methods, although
the risk here is lower than w/ adding methods to Array.prototype. Based on
the past, we won't find out about such problems until we ship.


On Mon, Nov 21, 2022 at 1:56 PM Yoav Weiss  wrote:

>
>
> On Fri, Nov 18, 2022 at 1:59 PM Marja Hölttä  wrote:
>
>> Contact emailsma...@chromium.org, s...@chromium.org
>>
>> Explainer
>> https://github.com/tc39/proposal-resizablearraybuffer/blob/master/README.md
>>
>> Specificationhttps://tc39.es/proposal-resizablearraybuffer/
>>
>> Summary
>>
>> Extend the ArrayBuffer constructors to take an additional maximum length
>> that allows in-place growth and shrinking of buffers. Similarly,
>> SharedArrayBuffer is extended to take an additional maximum length that
>> allows in-place growth.
>>
>>
>> Blink componentBlink>JavaScript>Language
>> 
>>
>> TAG review
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Interop risk exists in that resizing and growing the backing store, as
>> well as reserving the initial virtual memory, are platform and
>> OS-dependent. To that end the spec draft recommends implementation
>> guidelines:
>> https://tc39.es/proposal-resizablearraybuffer/#sec-maxbytelength-guidelines
>>
>>
>> *Gecko*: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1670026)
>> Assumed positive because this proposal is Stage 3 in TC39.
>>
>> *WebKit*: Positive Assumed positive because this proposal is Stage 3 in
>> TC39.
>>
>
> Do you know what their shipping plans are? Otherwise, what's the backwards
> compat story? Is there feature detection for this new capability?
>
>
>>
>> *Web developers*: No signals
>>
>> *Other signals*: -
>>
>> Security
>>
>> ArrayBuffers and TypedArrays are a leading vector of attack. The feature
>> has been designed to be implementable with a fixed data pointer to the
>> backing store. See
>> https://github.com/tc39/proposal-resizablearraybuffer#security The
>> security review has been done by the V8 Security team.
>>
>>
>> WebView application risks
>>
>> -
>>
>>
>>
>> Debuggability
>>
>> DevTools can already debug ArrayBuffers and SharedArrayBuffers.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Tested by test262
>>
>> Flag name--harmony-rab-gsab
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=1
>>
>> Estimated milestones
>>
>> M110
>>
>>
>> Anticipated spec changes
>>
>> Included in the proposal's spec
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/4668361878274048
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>>
>>
>> Google Germany GmbH
>>
>> Erika-Mann-Straße 33
>>
>> 80636 München
>>
>> Geschäftsführer: Paul Manicle, Liana Sebastian.
>>
>> Registergericht und -nummer: Hamburg, HRB 86891
>>
>> Sitz der Gesellschaft: Hamburg
>>
>> Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten
>> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
>> löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen,
>> dass die E-Mail an die falsche Person gesendet wurde.
>>
>>
>>
>> This e-mail is confidential. If you received this communication by
>> mistake, please don't forward it to anyone else, please erase all copies
>> and attachments, and please let me know that it has gone to the wrong
>> person.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAED6dUCUWtDVcF%3DvvLvZcC1ng2CDgtn0UufjjCCoj9kK9%2BqaOg%40mail.gmail.com
>> 
>> .
>>
>

-- 


Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian.

Registergericht und 

Re: [blink-dev] Intent to Ship: Resizable ArrayBuffer and growable SharedArrayBuffer

[Yoav Weiss]

On Fri, Nov 18, 2022 at 1:59 PM Marja Hölttä  wrote:

> Contact emailsma...@chromium.org, s...@chromium.org
>
> Explainer
> https://github.com/tc39/proposal-resizablearraybuffer/blob/master/README.md
>
> Specificationhttps://tc39.es/proposal-resizablearraybuffer/
>
> Summary
>
> Extend the ArrayBuffer constructors to take an additional maximum length
> that allows in-place growth and shrinking of buffers. Similarly,
> SharedArrayBuffer is extended to take an additional maximum length that
> allows in-place growth.
>
>
> Blink componentBlink>JavaScript>Language
> 
>
> TAG review
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Interop risk exists in that resizing and growing the backing store, as
> well as reserving the initial virtual memory, are platform and
> OS-dependent. To that end the spec draft recommends implementation
> guidelines:
> https://tc39.es/proposal-resizablearraybuffer/#sec-maxbytelength-guidelines
>
>
> *Gecko*: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1670026)
> Assumed positive because this proposal is Stage 3 in TC39.
>
> *WebKit*: Positive Assumed positive because this proposal is Stage 3 in
> TC39.
>

Do you know what their shipping plans are? Otherwise, what's the backwards
compat story? Is there feature detection for this new capability?


>
> *Web developers*: No signals
>
> *Other signals*: -
>
> Security
>
> ArrayBuffers and TypedArrays are a leading vector of attack. The feature
> has been designed to be implementable with a fixed data pointer to the
> backing store. See
> https://github.com/tc39/proposal-resizablearraybuffer#security The
> security review has been done by the V8 Security team.
>
>
> WebView application risks
>
> -
>
>
>
> Debuggability
>
> DevTools can already debug ArrayBuffers and SharedArrayBuffers.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?Tested by test262
>
> Flag name--harmony-rab-gsab
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=1
>
> Estimated milestones
>
> M110
>
>
> Anticipated spec changes
>
> Included in the proposal's spec
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/4668361878274048
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
>
>
> Google Germany GmbH
>
> Erika-Mann-Straße 33
>
> 80636 München
>
> Geschäftsführer: Paul Manicle, Liana Sebastian.
>
> Registergericht und -nummer: Hamburg, HRB 86891
>
> Sitz der Gesellschaft: Hamburg
>
> Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten
> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
> löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen,
> dass die E-Mail an die falsche Person gesendet wurde.
>
>
>
> This e-mail is confidential. If you received this communication by
> mistake, please don't forward it to anyone else, please erase all copies
> and attachments, and please let me know that it has gone to the wrong
> person.
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAED6dUCUWtDVcF%3DvvLvZcC1ng2CDgtn0UufjjCCoj9kK9%2BqaOg%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUcCY2Q%2BpKOPMKj-N-5542%2Bu_NXJv7cukEa90NBYTf6Lw%40mail.gmail.com.

[blink-dev] Intent to Ship: Resizable ArrayBuffer and growable SharedArrayBuffer

[Marja Hölttä]

Contact emailsma...@chromium.org, s...@chromium.org

Explainer
https://github.com/tc39/proposal-resizablearraybuffer/blob/master/README.md

Specificationhttps://tc39.es/proposal-resizablearraybuffer/

Summary

Extend the ArrayBuffer constructors to take an additional maximum length
that allows in-place growth and shrinking of buffers. Similarly,
SharedArrayBuffer is extended to take an additional maximum length that
allows in-place growth.


Blink componentBlink>JavaScript>Language


TAG review

TAG review statusNot applicable

Risks


Interoperability and Compatibility

Interop risk exists in that resizing and growing the backing store, as well
as reserving the initial virtual memory, are platform and OS-dependent. To
that end the spec draft recommends implementation guidelines:
https://tc39.es/proposal-resizablearraybuffer/#sec-maxbytelength-guidelines


*Gecko*: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1670026)
Assumed positive because this proposal is Stage 3 in TC39.

*WebKit*: Positive Assumed positive because this proposal is Stage 3 in
TC39.

*Web developers*: No signals

*Other signals*: -

Security

ArrayBuffers and TypedArrays are a leading vector of attack. The feature
has been designed to be implementable with a fixed data pointer to the
backing store. See
https://github.com/tc39/proposal-resizablearraybuffer#security The security
review has been done by the V8 Security team.


WebView application risks

-



Debuggability

DevTools can already debug ArrayBuffers and SharedArrayBuffers.


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests

?Tested by test262

Flag name--harmony-rab-gsab

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=1

Estimated milestones

M110


Anticipated spec changes

Included in the proposal's spec


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/4668361878274048

This intent message was generated by Chrome Platform Status
.

-- 


Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian.

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten
haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen,
dass die E-Mail an die falsche Person gesendet wurde.



This e-mail is confidential. If you received this communication by mistake,
please don't forward it to anyone else, please erase all copies and
attachments, and please let me know that it has gone to the wrong person.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAED6dUCUWtDVcF%3DvvLvZcC1ng2CDgtn0UufjjCCoj9kK9%2BqaOg%40mail.gmail.com.