file-system-access

file-system-access copied to clipboard

In https://github.com/web-platform-tests/wpt/pull/21301 I couldn't find a way to create instances of the interfaces defined by this spec in a testing environment. This is probably also why all of the native_* tests in https://github.com/web-platform-tests/wpt/tree/master/native-file-system are manual.

The spec does refer to https://w3c.github.io/permissions/ but doesn't seem to define any new entry for https://w3c.github.io/permissions/#permission-registry.

If permissions is the right model for this, then that would also take care of test automation, since we have a mechanism in WebDriver for setting permissions and that's used in wpt: https://web-platform-tests.org/writing-tests/testdriver.html#set-permission

In web-platform-tests/wpt#21301 I couldn't find a way to create instances of the interfaces defined by this spec in a testing environment.

Creating instances of all the interfaces shouldn't require any special test automation, the sandboxed file system should work without any kind of permissions. I.e. let dir = await FileSystemDirectoryHandle.getSystemDirectory({ type: "sandbox" }) gives you a FileSystemDirectoryHandle, and let file = await dir.getFile('name', {create: true}) then gives you a FileSystemFileHandle instance.

This is probably also why all of the native_* tests in https://github.com/web-platform-tests/wpt/tree/master/native-file-system are manual.

FWIW I recently added chrome specific test automation in https://chromium-review.googlesource.com/c/chromium/src/+/1989369. Unfortunately that means I'm a little less motivated to figure out how to do that properly/upstream as that solved my immediate problem of not having test coverage.

The spec does refer to https://w3c.github.io/permissions/ but doesn't seem to define any new entry for https://w3c.github.io/permissions/#permission-registry.

If permissions is the right model for this, then that would also take care of test automation, since we have a mechanism in WebDriver for setting permissions and that's used in wpt: https://web-platform-tests.org/writing-tests/testdriver.html#set-permission

The permissions bit might (eventually) solve part of the story, but that doesn't do anything to actually somehow select a file or directory in a file picker in the first place. I.e. we might be able to use that to grant write access to a selected directory, but to select a usable directory in the first place more will be needed. In the above mentioned chrome specific automation I solved this by adding two new methods, one the test can call to set the path that should be returned by all subsequent file chooser dialogs, and another one that returns an empty writable (temporary) directory the test can use.

TestDriver does have some automation for something sort of similar with , but that works be emulating keyboard events on the input element, and with this API there is no html element, just a javascript API. I.e. that approach doesn't work here. Also I don't think WPT currently provides a way to get a directory the tests can use in which the browser/test is also allowed to write.

Anyway, I'd welcome any input as to how to do this better, although for at least the next couple of months I won't be able to invest much time in this. Happy to review/discuss etc whatever options other people come up with though.

Thanks for the details, @mkruisselbrink!

I see that @Hexcles reviewed https://chromium-review.googlesource.com/c/chromium/src/+/1989369, but cc @LukeZielinski @stephenmcgruer for visibility.

It sounds like a fairly simple WebDriver API in the style of setFilePathForMockFileDialog might suffice here, one that says "when chooseFileSystemEntries() is called, use this directory". We would like it to be so straightforward to extend WebDriver and plug this through that there's not much overhead compared to a vendor-specific solution, but that isn't yet the case. @LukeZielinski, can you add this to your test automation tracking?

Ack, added to tracking.

#200 partially addresses at least the permissions side of this (the file picker part will still need its own test API), with the caveat that as currently written the permission descriptors defined by #200 aren't json serializable, and thus can't be passed over the webdriver API. We could invent some kind of handle-id to be used in permission descriptors instead of the handles themselves (or perhaps allow either), but that seems weird to. I think ideally the webdriver permission API would use paths while the JS api keeps using handles, but doing something like that will require changes to the permissions spec to support different permission descriptor types/steps for webdriver vs js.

Anyway, probably not going to get to further figuring this out in the too near future.