[whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

[Kinuko Yasuda]

On Fri, Nov 18, 2011 at 1:00 PM, Glenn Maynard <glenn at zewt.org> wrote:
> On Thu, Nov 17, 2011 at 10:47 PM, Kinuko Yasuda <kinuko at chromium.org> wrote:
>>
>> I mean the URL would essentially be a weak reference to the backing
>> file, but it won't keep the backing file alive.
>> (At least in sandboxed cases) the filesystem URLs are more like
>> 'public address' and not coupled with any particular Entry instances.
>> One can make up a URL just by concatenating strings and then can get
>> the Entry from the URL.
>
> Right, but we're talking about the non-sandboxed case.
>
>> What I'm going to do is: create a set of capabilities upon drag event,
>> give the capabilities to the context when it was dropped, and revoke
>> the capabilities when the context gets deleted (i.e. the page is
>> closed).  The lifetime of the Entry instance object doesn't matter in
>> this case; Entry is yet another weak reference to the backing file but
>> doesn't mean a live reference or access right.
>
> This implies a memory leak, as each time you drag a file into a page, you
> permanently (for the lifetime of the document) create a record that the page
> is allowed to access that file.  If you drag lots of individual files into
> the page, this leak could become nontrivial.  I don't think a design with
> inherent memory leaks is a good direction.

I would say the approach has a bloating per-page bookkeeping problem but
not a 'leak'.  Actually chrome does record such per-file/per-directory
permission
for each page regardless of whether we support DirectoryEntry or not, and
so far our observation tells that the amount of memory necessary to keep such
permission is negligibly small.  If we needed to keep actual data in-memory
along with the permission (like we do for Blob) the problem would have been
serious but I don't think that'd be a big issue in this case.

> --
> Glenn Maynard
>
>