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. > The spec on this could be nudged slightly to support Chrome's existing > behavior. > > 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." > > Given that the underlying file can change, and the FileList sequence is > live, it seems reasonable that subsequent reads of FileList would access a > different File object when the underlying file has changed. > > FileList.onchanged would be appropriate. File.onupdated would not be > appropriate. Entry.onupdated would be appropriate. > > >> I have one major technical concern: monitoring files for changes isn't >> free. With only a DOM event, all instantiated Files (or Entries) would have >> to monitor changes; you don't want to depend on "do something if an event >> handler is registered", since that violates the principle of event handler >> registration having no other side-effects. Monitoring should be enabled >> explicitly. >> >> I also wonder whether this could be implemented everywhere, eg. on mobile >> systems. >> > > At this point, iOS still doesn't allow <input type="file"> nor dataTransfer > of file. So, we're looking far ahead. > > A system may send a FileList.onchanged() event when it notices that the > FileList has been updated. It can be done on access of a live FileList when > a mutation is detected. It could be done by occasional polling, or it could > be done via notify-style OS hooks. In the first case, there is no > significant overhead. webkitdirectory returns a FileList object that can be > monitored via directory notification hooks; again, if the OS supports it. > > Event handlers have some side effects, but not in the scripting environment. > onclick, for example, may mean that an element responds to touch events in > the mobile environment. > > > -Charles > >