search

whatwg / fs

File System Standard
https://fs.spec.whatwg.org/
Other
229 stars 19 forks source link

working together with async clipboard api #33

Open jimmywarting opened 2 years ago

jimmywarting commented 2 years ago

it would be pretty sweet if it where possible to write a FileSystemFileHandle or FileSystemDirectoryHandle to the clipboard as a way of copying something from the sandboxed navigator.storage.getDirectory into the users own folder of choice

await navigator.clipboard.write([ 
  await navigator.storage.getDirectory()
  // ...more fileHandle(s)
])
a-sully commented 2 years ago

Interesting idea... The big question with clipboard is what to actually put on the clipboard. The async clipboard API doesn't currently support files (though we're hoping to change that at some point) and I don't believe that includes plans to put directories on the clipboard. I'll link this issue in our tracking bug so this stays on our radar once clipboard files support is added.

Regardless, this use case should be satisfied soon anyways, since we're hoping to allow move() to support moving files and directories from the sandboxed file system to a folder of the user's choice.

tomayac commented 2 years ago

Regardless, this use case should be satisfied soon anyways, since we're hoping to allow move() to support moving files and directories from the sandboxed file system to a folder of the user's choice.

TIL that this is on the roadmap. We should then probably update this section of the AccessHandle explainer and set expectations that OPFS→regular FS is a flow we want to enable.

a-sully commented 2 years ago

The Storage Foundation API did not deal with files on the user's machine, but put files in a separate sandboxed file system. (and Storage Foundation never launched, so that comment can probably be removed soon anyways)

OPFS→regular FS is discussed in the move() PR which I've been meaning to clean up...

a-sully commented 2 years ago

This actually came up in a recent discussion. We're still a ways away from adding support for this, but a somewhat more thought through design for supporting this use case is sketched out in my latest comment on the bug

jimmywarting commented 2 years ago

how about allowing to write files within a secure context and only allow it on a top-level pages and no iframes?

a-sully commented 2 years ago

When downloading files, we still run safe-browsing checks in this case. Allowing files to be written to the clipboard (which can then be pasted into a file explorer) without running safe-browsing checks would effectively provide a work-around for these checks. The sandboxed file system was on my mind because we're looking into the move() case, but we might need to run these checks on any file written onto the clipboard by the browser

Which isn't without precedence. We currently sanitize images before writing them to the clipboard.

jimmywarting commented 2 years ago

🤔 just thinking to myself if i get access to a user directory or file that a person already have on their file system from this new showOpenFilePicker, showDirectoryPicker (aka not from the sandboxed filesystem - OPFS) would it then be safe to copy them to clipboard?

a-sully commented 2 years ago

I agree, and my hope is what we can find an intelligent way to do this which allows us to not scan every file put on the clipboard.

What we want to avoid is a site being able to put arbitrary data in a File, write it to the clipboard, and have it pasted into the user's local file system (in what would effectively be a download) without having safe-browsing checks run on it.

I'll re-open this issue since I could see this being added sometime in the future, but in the shorter term I hope allowing move() of files outside of the OPFS will at least help address the current feature gap.