Meziantou.Framework

fs

edit

WPT coverage of the tests of fs at the revision 5602b0f210e3. The tests link to their results in the browsers on wpt.fyi. The tentative tests (experimental features) and the reftests are listed separately from the stable tests.

GroupPassingTestsDisabledPass rate
Stable3235091%
Tentative28025%
Reftests000–
All3443079%

Failure reasons

The tests that do not pass (failing or disabled), by kind of reason. A test with several reasons counts once per kind.

  • TEST BUG: 1
  • NOT IMPLEMENTED: 8

Stable tests

TestResultSubtestsKindDescription
FileSystemBaseHandle-IndexedDB-deferred-deserialization.https.any.jsPass6 / 6
FileSystemBaseHandle-IndexedDB.https.any.jsPass18 / 18
FileSystemBaseHandle-buckets.https.any.jsFail0 / 9NOT IMPLEMENTEDStorage Buckets API (navigator.storageBuckets, whose buckets have their own file system); only Chromium implements it
FileSystemBaseHandle-getUniqueId.https.any.jsFail0 / 33NOT IMPLEMENTEDFileSystemHandle.getUniqueId(), a proposal (https://github.com/whatwg/fs/pull/46) that is not in the File System Standard; the test fails in every browser
FileSystemBaseHandle-isSameEntry.https.any.jsPass42 / 42
FileSystemBaseHandle-postMessage-BroadcastChannel.https.window.jsPass1 / 1
FileSystemBaseHandle-postMessage-Error.https.window.jsPass10 / 10
FileSystemBaseHandle-postMessage-MessagePort-frames.https.window.jsPass4 / 4
FileSystemBaseHandle-postMessage-MessagePort-windows.https.window.jsPass3 / 3
FileSystemBaseHandle-postMessage-MessagePort-workers.https.window.jsPass3 / 3
FileSystemBaseHandle-postMessage-frames.https.window.jsPass4 / 4
FileSystemBaseHandle-postMessage-insecure-context.https.window.jsPass3 / 3
FileSystemBaseHandle-postMessage-windows.https.window.jsPass3 / 3
FileSystemBaseHandle-postMessage-workers.https.window.jsPass3 / 3
FileSystemBaseHandle-remove.https.any.jsPass27 / 27
FileSystemDirectoryHandle-getDirectoryHandle.https.any.jsPass30 / 30
FileSystemDirectoryHandle-getFileHandle.https.any.jsPass39 / 39
FileSystemDirectoryHandle-iteration.https.any.jsPass18 / 18
FileSystemDirectoryHandle-removeEntry.https.any.jsPass39 / 39
FileSystemDirectoryHandle-resolve.https.any.jsPass15 / 15
FileSystemFileHandle-create-sync-access-handle.https.window.jsPass1 / 1
FileSystemFileHandle-getFile.https.any.jsPass9 / 9
FileSystemFileHandle-move.https.any.jsPass72 / 72
FileSystemSyncAccessHandle-close.https.worker.jsPass6 / 6
FileSystemSyncAccessHandle-flush.https.worker.jsPass2 / 2
FileSystemSyncAccessHandle-getSize.https.worker.jsPass1 / 1
FileSystemSyncAccessHandle-read-write.https.worker.jsPass14 / 14
FileSystemSyncAccessHandle-truncate.https.worker.jsPass3 / 3
FileSystemWritableFileStream-piped.https.any.jsPass24 / 24
FileSystemWritableFileStream-write.https.any.jsPass93 / 93
FileSystemWritableFileStream.https.any.jsFail24 / 27TEST BUGcreateWritable() can be called on two handles representing the same file calls createDirectory(t, 'parent_dir', root) and createEmptyFile(t, file_name, dir) with the test as first argument (the helpers take the name then the parent), so it calls getDirectoryHandle() on a string; it fails in every browser
idlharness.https.any.jsPass140 / 140
opaque-origin.https.window.jsPass3 / 3
opfs-shared-worker-coep.https.window.jsPass1 / 1
root-name.https.any.jsPass3 / 3

Tentative tests

TestResultSubtestsKindDescription
FileSystemFileHandle-cross-primitive-locking.https.tentative.worker.jsError64 / 90NOT IMPLEMENTEDthe locks of the move() and remove() operations in progress (the locking proposal of Chromium, not in the File System Standard): the test starts a move or a removal without waiting for it and expects another primitive to be rejected meanwhile, but the operations of the library are done when they are called, so the primitive is created and its lock is not released by the test (the following subtests then fail on the leaked lock); the locks of the writable streams and of the access handles pass, and the test also fails in Chromium (66 of 90)
FileSystemFileHandle-sync-access-handle-back-forward-cache.https.tentative.window.jsFail1 / 2NOT IMPLEMENTEDthe back/forward cache does not keep a document with an open FileSystemSyncAccessHandle (the browsers keep it and evict it when an active document needs a contentious lock on the file): the document is destroyed by the navigation, which releases its access handles, so the second subtest's history.back() loads it again
FileSystemFileHandle-sync-access-handle-lock-modes.https.tentative.worker.jsPass33 / 33
FileSystemFileHandle-writable-file-stream-back-forward-cache.https.tentative.window.jsFail1 / 2NOT IMPLEMENTEDthe back/forward cache does not keep a document with an open FileSystemWritableFileStream (the browsers keep it and evict it when an active document needs a contentious lock on the file): the document is destroyed by the navigation, which aborts its streams, so the BFCache executor reports a failed precondition
FileSystemFileHandle-writable-file-stream-lock-modes.https.tentative.worker.jsPass15 / 15
FileSystemObserver-sync-access-handle.https.tentative.worker.jsFail0 / 4NOT IMPLEMENTEDFileSystemObserver, a proposal (https://github.com/whatwg/fs/blob/main/proposals/FileSystemObserver.md) that is not in the File System Standard; only Chromium implements it
FileSystemObserver-writable-file-stream.https.tentative.any.jsFail0 / 6NOT IMPLEMENTEDFileSystemObserver, a proposal (https://github.com/whatwg/fs/blob/main/proposals/FileSystemObserver.md) that is not in the File System Standard; only Chromium implements it
FileSystemObserver.https.tentative.any.jsFail0 / 48NOT IMPLEMENTEDFileSystemObserver, a proposal (https://github.com/whatwg/fs/blob/main/proposals/FileSystemObserver.md) that is not in the File System Standard; only Chromium implements it