Re: File modification

On Wed, Jan 11, 2012 at 12:22 PM, Charles Pritchard <chuck@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
>
>

Received on Wednesday, 11 January 2012 20:34:31 UTC