On 1/11/2012 12:27 PM, Eric U wrote:
On Wed, Jan 11, 2012 at 12:22 PM, Charles Pritchard<ch...@jumis.com> wrote:
On 1/11/2012 9:00 AM, Glenn Maynard wrote:
This isn't properly specced anywhere and may be impossible to implement
perfectly, but previous discussions indicated that Chrome, at least, wanted
File objects loaded from input elements to only represent access for the
file as it is when the user opened it. That is, the File is immutable (like
a Blob), and if the underlying OS file changes (thus making the original
data no longer available), attempting to read the File would fail. (This
was in the context of storing File in structured clone persistent storage,
like IndexedDB.)
Mozilla seems to only take a snapshot when the user opens the file. Chrome
goes in the other direction, and does so intentionally with FileEntry.
I'd prefer everyone follow Chrome.
We do so with FileEntry, in the sandbox, because it's intended to be a
much more powerful API than File, and the security aspects of it are
much simpler. When the user drags a File into the browser, it's much
less clear that they intend to give the web app persistent access to
that File, including all future changes until the page is closed. I
don't think we'd rush to make that change to the spec. And if our
implementation isn't snapshotting currently, that's a bug.
In my reading of the spec, UAs explicitly instructed not to implement a
snapshot. Everything in the specs talks about underlying data.
They are to keep the FileList live, and failing that, or should the
underlying file be removed, they should throw an error when the File
object is used with FileReader or the like.
I've written code for Chrome that detects file changes, so it'd be a bit
of a bummer to see this feature removed without suitable replacement.
FileEntry does not currently work with D&D as well as File. I don't
think it's caught up yet. I can't drag a FileEntry into <input
type="file"> on another site.
From drag&drop:
http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html
"The files attribute must return a live FileList sequence...".
http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#live
"If a DOM object is said to be live, then the attributes and methods on that
object must operate on the actual underlying data, not a snapshot of the
data."
Drag&drop continues:
"for a given FileList object and a given underlying file, the same File
object must be used each time."
"Underlying" is an important distinction here.
For persistent directory access, we talked about using
requestFileSystem(MOUNT).
-Charles
