Intent to Prototype: FileAPI: Blob.bytes()

[Chromestatus]

Contact emails

zees...@gmail.com, zi...@chromium.org

Explainer

None

Specification

https://www.w3.org/TR/FileAPI

Design docs

https://w3c.github.io/FileAPI/#dom-blob-bytes

Summary

The bytes() method of the Blob interface returns a Promise that resolves with a Uint8Array containing the contents of the blob as an array of bytes.

Blink component

Blink>Storage>FileAPI

Motivation

Developers currently need to invoke the arrayBuffer method on a Blob and then convert the result into a Uint8Array whenever they want raw bytes. Blob.bytes collapses this two-step ritual into a single call, returning a Uint8Array. By removing the extra allocation and copy, it trims garbage-collection overhead and lowers latency when processing large blobs.

Initial public proposal

None

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Safari 18 and Firefox 128 have already shipped the feature.

Gecko: Shipped/Shipping (https://www.firefox.com/en-US/firefox/128.0/releasenotes)

WebKit: Shipped/Shipping (https://webkit.org/blog/15865/webkit-features-in-safari-18-0)

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

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

Yes

https://wpt.fyi/results/FileAPI/Blob-methods-from-detached-frame.html https://wpt.fyi/results/FileAPI/blob/Blob-bytes.any.html https://wpt.fyi/results/FileAPI/blob/Blob-bytes.any.worker.html

Flag name on about://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4830298126417920?gate=4565118389846016

This intent message was generated by Chrome Platform Status.

[Gregg Tavares]

Just curious, I saw this go by

>  Blob.bytes collapses this two-step ritual into a single call, returning a Uint8Array. By removing the extra allocation and copy, it trims garbage-collection overhead and lowers latency when processing large blobs.

There should be no extra allocation as it is

     const bytes = new Uint8Array(async someBlob.arrayBuffer())

Does not make 2 allocations (AFAIK). It makes one allocation (the array buffer). And it makes TypeArrayView of that same array buffer

--
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+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/688952f5.2b0a0220.35091d.0040.GAE%40google.com.

[Suyeon Ji]

Hi, Thanks for the review.

you’re absolutely correct. I misinterpreted some of the background details while reviewing them.

My apologies for any confusion this may have caused. Your feedback made me review it again, and I’ve updated the motivation section accordingly.

Updated motivation section

Before this change developers could not access an ArrayBuffer directly and had to create a Uint8Array view, and some APIs returned different types which leading to inconsistency.

To improve this, design principles have changed[1] in w3c tag side, so the spec was updated[2] accordingly.  The new spec removes those hassles, and because WebKit, Firefox and Node.js already support it, bringing it to Chromium will improve interoperability as well.

[1] https://github.com/w3ctag/design-principles/issues/463
[2] https://github.com/w3ctag/design-principles/pull/480
[3] https://github.com/w3c/FileAPI/pull/198

chromestatus: https://chromestatus.com/feature/4830298126417920

2025년 8월 1일 금요일 오전 7시 3분 30초 UTC+9에 gm...@chromium.org님이 작성: