Correct handling of resizable ArrayBuffer?
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 30/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- javascript
- Lĩnh vực
- web-dev
Hướng nghiên cứu
Issue không nêu tên tệp nào trong repository hoặc các test. Trước tiên, hãy xác định hành vi mong đợi khi xây dựng Blob nếu TypedArray nguồn sử dụng một resizable ArrayBuffer và kích thước của nó bị thay đổi trong quá trình sao chép, sau đó ghi lại hành vi đã chọn và việc specification có nên yêu cầu một lỗi hay một kết quả khác hay không.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Given const b = new Blob([A, B]), where A is a TypedArray with a resizable ArrayBuffer, what is the expected behavior?
Chrome/Firefox currently both throw an error if any of the source ArrayBuffer instances are resizable; other runtimes do not.
There is an issue here if A is resized while the Blob is being constructed and the data is being copied. This can happen, for instance, if B has a getter for it's length that causes A to be resized and the implementation uses a flow like...
let total = 0;
for (const chunk of chunks) {
total += chunk.length; // B could resize A as a side effect here
}
const dest = allocate(total);
for (const chunk of chunks) {
copy chunk into dest
}
Let's suppose that A and B both initially have length 10, but B's length getter resizes A to 5... what should the result be?
- Length 15, with 5 bytes from A, 10 bytes from B, allocation gets trimmed at the end of the copy
- Length 20, with 5 bytes from A, 10 bytes from B, and 5 zeroed bytes at the end?
- Length 20, with 5 bytes from A, 5 zeroed bytes, 10 bytes from B
- Error thrown because length changed?
- Something else?
What if A is resized larger? Is the result just truncated?
Should the spec for Blob explicitly make Chrome/Firefox's behavior of throwing immediately on resizable ArrayBuffer's standard? etc.
/cc @guybedford
- Ngôn ngữ chính
- HTML
- Star
- 118
- Fork
- 52
- Merge trung bình
- 9 ngày 16 giờ
- Pull request đã merge (30 ngày)
- 1
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của w3c/FileAPI
-
TPAC 2026 Status Report Đang mởTPAC2026
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
-
Broken references in File API Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 62/100
-
Add accessibility section Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
[Block] Latest Posts [Type] Bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
gitbutlerapp/gitbutler#15998 · 1 bình luận ·
-
t/bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
-
task
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100