Bug 177709 – [macOS] On APFS, consider copying dropped or pasted files into app container instead of adding sandbox extensions

• Status: NEW
• Component: HTML Editing

[Ryosuke Niwa]

On iOS, we never have to add sandbox extensiosns to drag dropped files or pasted files because we copy them into the WebContent process' app container. We should consider doing the same on macOS if the files are located in the same APFS container as the system volume.

[Alexey Proskuryakov]

I don't think that copying is compatible with File API semantics - we are supposed to let the web app know when the file is modified beneath them.

[Ryosuke Niwa]

I'm not certain if that API semantics is really important for compatibility. If the user dropped a file onto a website, he/she probably doesn't expect a website to have access to a random file which happens to have the same file path sometime later.

[Alexey Proskuryakov]

If I'm uploading a text file, and I edit it between dropping and uploading, I absolutely don't expect the old version to be uploaded. I want the updated version, and if that can't be done, I want the website to ask me about what to do. That's what the API provides for.

[Ryosuke Niwa]

(In reply to Alexey Proskuryakov from comment #3)
> If I'm uploading a text file, and I edit it between dropping and uploading,
> I absolutely don't expect the old version to be uploaded. I want the updated
> version, and if that can't be done, I want the website to ask me about what
> to do. That's what the API provides for.

I'm not sure about that. I would be annoyed by that semantics. If I'm drag & dropped a file A, then I would that exact file & its content at the time of the drop to be uploaded. Furthermore, if I rename file A, and then rename another file B to be of the old name of A, then I wouldn't expect B to be uploaded.

[Alexey Proskuryakov]

That's how it works in Safari now, did you run into problems because of it? Personally, I've sent the wrong attachment with Mail several times, which uses the approach you suggest.

[Geoffrey Garen]

Whichever way we go on this, I don't think we want the behavior to differ based on filesystem type. Web API behaviors should be consistent across devices.

Relatedly, we should test what other browsers do.

[Ryosuke Niwa]

Agreed that we shouldn't have a different behavior based on filesystems.

[Darin Adler]

Not sure if this comment is relevant to this bug, but I think there are two separate issues here:

1) What happens if a file's content is changed before the user triggers the user interface that starts the file uploading process. Certainly on legacy computer user interfaces like the one on a Mac it’s expected that the latest version of the file is uploaded, not a snapshot from back when the file was selected (chosen from a dialog, dragged, whatever). I’m guessing we’d expect the same thing from the file system on iOS, but a truly modern file system might get rid of the concept of "overwriting" a file.

2) What happens if a file's content is changed during the uploading process. In this case, I consider it a bug that you can upload a "damaged" file where content from two versions is mixed together, just because you made changes while the computer was sending data over the network.

I think it’s reasonable to consider fixing (2) even if it is practical to do it only on APFS. I think that kind of difference between file systems would be acceptable.