2021767 - FileSystemWritableFileStream: WriteParams members (size, position, data) should be non-nullable per updated spec

Status: UNCONFIRMED

(Core :: DOM: File, defect, P3)

Description

[Usama Nadeem]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36

Steps to reproduce:

The WHATWG File System spec has been updated to make the size, position, and data members of the WriteParams dictionary non-nullable.

Spec change: https://github.com/whatwg/fs/pull/182
Related issue: https://github.com/whatwg/fs/issues/181
WPT tests: https://github.com/web-platform-tests/wpt/pull/58156

Call FileSystemWritableFileStream.write() passing null for size, position, or data in the WriteParams dictionary.

Actual results:

No TypeError is thrown — null is accepted silently or causes unexpected behavior.

Expected results:

A TypeError should be thrown at the WebIDL boundary when null is passed for size, position, or data in WriteParams, as these members are now non-nullable per the updated WHATWG File System spec.

Comment 1

[Usama Nadeem]

Hi, just wanted to provide an update on the status of the upstream spec change that this bug tracks.

Spec PR status (whatwg/fs#182):
The PR removing the nullable markers from WriteParams members (size, position, data) is open and under review: https://github.com/whatwg/fs/pull/182

All requested items have been completed:

• WPT tests added for position: null and size: null throwing TypeError: https://github.com/web-platform-tests/wpt/pull/58156
• Implementation bugs filed for all three engines (Chromium: https://issues.chromium.org/issues/490640057, Gecko: this bug, WebKit: https://bugs.webkit.org/show_bug.cgi?id=309446)
• The spec PR has been reviewed by @annevk and is awaiting sign-off from @a-sully or @mkruisselbrink (assigned 3 weeks ago)

Once the spec PR merges, the expectation is that Gecko (and other engines) will need to update their FileSystemWritableFileStream.write() implementation to reject null for these members at the WebIDL boundary.

Happy to provide any additional context needed from the Mozilla side. Thank you!