Browserify Buffer's #subarray() no longer works (returns full array without slicing)

RESOLVED INVALID

Status

()

Core
JavaScript: Standard Library
RESOLVED INVALID
2 years ago
2 years ago

People

(Reporter: Bob, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
Calling #subarray() on a object that inherits from TypedArray incorrectly returns the full array.

This affects the Browserify "Buffer" library, which could potentially affect a lot of sites.

This seems very similar to bug 1145058 from about a year ago.

Based on the pushlog, I suspect bug 1165053 caused this regression.

---

Full test case, w/ Browserify: http://requirebin.com/?gist=19e9aeef88364c531c258fb713a2e068

Incorrect output:

> Uint8Array [ 0, 1, 2 ]
> Uint8Array [ 0, 1, 2 ]
> Uint8Array [ 0, 1, 2 ]
> Uint8Array [ 0, 1, 2 ]

Correct/expected output:

> Uint8Array [  ]
> Uint8Array [ 0 ]
> Uint8Array [ 0, 1 ]
> Uint8Array [ 0, 1, 2 ]

Attempt at a minimal test case: http://codepen.io/Bob_Vul/pen/BzNKbz

These work on both the current Firefox and Chrome release versions.

---

Last good: mozilla-inbound 9f6afb62 2016-04-07 10:51:30.766000
First bad: mozilla-inbound 4d0f975a 2016-04-07 12:35:16.262000
Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9f6afb62fe80ee168a90577957d1c53ad9fe8ecd&tochange=4d0f975a23119a61a6c8e5856125de2db5713c49
NI arai because of the regression range :)
Flags: needinfo?(arai.unmht)
(Reporter)

Comment 2

2 years ago
As an example of real-world breakage, pdfmake[1] no longer works when large PNG images are included because it tries and fails to slice the Buffer into 65k chunks.

Example: http://codepen.io/Bob_Vul/pen/vKOLed

[1]: http://pdfmake.org/playground.html
Seems like an incompatible change in the spec, as es6draft also returns entire array.
will check what the actual difference is.
now @@species is supported, and `Buffer[@@species]` (== Buffer) is used instead of Uint8Array while creating subarray.

The "Buffer" constructor doesn't support `TypedArray(buffer, byteOffset, length)` style call properly, as it ignores 2nd and 3rd arguments.
https://tc39.github.io/ecma262/#sec-typedarray-buffer-byteoffset-length

That results in copying entire array.

So, I think this should be addressed in Browserify's side.
Flags: needinfo?(arai.unmht)
If the "buffer" comes from this https://github.com/feross/buffer , looks like the library is updated from the one that is used in the testcase, as it has 3 parameters.
https://github.com/feross/buffer/blob/master/index.js#L99

> function Buffer (arg, encodingOrOffset, length) {
so, where does the "buffer" module come from?  and which revision does the testcase use?
Flags: needinfo?(bob+bmo)
(Reporter)

Comment 7

2 years ago
Thanks for looking into this, and my apologies for neglecting to check if there was an update! I had assumed that RequireBin used the latest, but evidently there's some caching going on (over at wzrd.in, actually, where even explicitly requesting 4.6.0 returns an older version... hmm). The current npm version, 4.6.0, contains the changes you mentioned.

I'll try to get pdfmake to update, and hopefully others will too.

Sorry about the trouble.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(bob+bmo)
Resolution: --- → INVALID
Summary: Prototypal inheritance of TypedArray breaks #subarray() (returns full array without slicing) → Browserify Buffer's #subarray() no longer works (returns full array without slicing)

Updated

2 years ago
Duplicate of this bug: 1295841
You need to log in before you can comment on or make changes to this bug.