Thanks for the feedback.
On Fri, Sep 14, 2012 at 6:58 AM, Ian Hickson wrote:
> On Tue, 15 Nov 2011, Kinuko Yasuda wrote:
> >
> > Many sites have 'upload your files' feature, like for your photo images.
> > HTML5 allows you to do this via or
> > drag-and-drop feature, but the current solution do
On Thu, 13 Sep 2012 23:58:42 +0200, Ian Hickson wrote:
However, both exposing the hiearchy and flattening it have all kinds of
risks. It's possible for the user to accidentally expose his entire
computer's hard drive without realising it. On some systems (including at
least modern Mac OS and Li
On Tue, 15 Nov 2011, Kinuko Yasuda wrote:
>
> Many sites have 'upload your files' feature, like for your photo images.
> HTML5 allows you to do this via or
> drag-and-drop feature, but the current solution does not provide clean
> solution for cases with folders, files/folder mixed cases, or f
Apologies for my late response.
On Tue, Apr 10, 2012 at 7:33 AM, Glenn Maynard wrote:
> On Mon, Apr 9, 2012 at 3:35 AM, Kinuko Yasuda wrote:
>
>> I don't think we should do this. The change would be invasive and could
>> delay firing a drop event indefinitely if the number of dropped files i
On Mon, Apr 9, 2012 at 3:35 AM, Kinuko Yasuda wrote:
> I don't think we should do this. The change would be invasive and could
> delay firing a drop event indefinitely if the number of dropped files is
> very huge.
>
This feels like the wrong optimization. It's making this API more
cumbersome
On Thu, Apr 5, 2012 at 8:52 PM, Glenn Maynard wrote:
> On Wed, Apr 4, 2012 at 11:36 PM, Kinuko Yasuda wrote:
>
>> A follow up about this proposal:
>>
>> Based on the feedbacks we got on this list we've implemented the following
>> API to do experiments in Chrome:
>> DataTransferItem.getAsEntry(i
uOn Fri, Apr 6, 2012 at 10:37 PM, Glenn Maynard wrote:
> On Thu, Apr 5, 2012 at 11:42 PM, Kinuko Yasuda wrote:
>
>> Does this actually need to be async? The only information you need to
>> create the Entry are the filename and the file type (file or directory),
>> which the browser can load befo
On Thu, Apr 5, 2012 at 11:42 PM, Kinuko Yasuda wrote:
> Does this actually need to be async? The only information you need to
> create the Entry are the filename and the file type (file or directory),
> which the browser can load before performing the drop, so no file I/O is
> needed here.
>
> I
On Fri, Apr 6, 2012 at 12:52 PM, Glenn Maynard wrote:
> On Wed, Apr 4, 2012 at 11:36 PM, Kinuko Yasuda wrote:
>
>> A follow up about this proposal:
>>
>> Based on the feedbacks we got on this list we've implemented the
>> following API to do experiments in Chrome:
>> DataTransferItem.getAsEntry(
On Wed, Apr 4, 2012 at 11:36 PM, Kinuko Yasuda wrote:
> A follow up about this proposal:
>
> Based on the feedbacks we got on this list we've implemented the following
> API to do experiments in Chrome:
> DataTransferItem.getAsEntry(in EntryCallback callback)
>
Does this actually need to be asy
On Fri, Apr 6, 2012 at 12:32 AM, Eric U wrote:
> On Wed, Apr 4, 2012 at 9:36 PM, Kinuko Yasuda wrote:
> > A follow up about this proposal:
> >
> > Based on the feedbacks we got on this list we've implemented the
> following
> > API to do experiments in Chrome:
> > DataTransferItem.getAsEntry(in
On Wed, Apr 4, 2012 at 9:36 PM, Kinuko Yasuda wrote:
> A follow up about this proposal:
>
> Based on the feedbacks we got on this list we've implemented the following
> API to do experiments in Chrome:
> DataTransferItem.getAsEntry(in EntryCallback callback)
>
> which takes a callback that return
A follow up about this proposal:
Based on the feedbacks we got on this list we've implemented the following
API to do experiments in Chrome:
DataTransferItem.getAsEntry(in EntryCallback callback)
which takes a callback that returns FileEntry or DirectoryEntry if it's for
drop event and the item'
On Sat, Nov 19, 2011 at 7:37 AM, Glenn Maynard wrote:
> On Fri, Nov 18, 2011 at 1:36 AM, Kinuko Yasuda wrote:
>>
>> I would say the approach has a bloating per-page bookkeeping problem but
>> not a 'leak'.
>
> It's a reference leak: an object which remains referenced after it's no
> longer needed
On Fri, Nov 18, 2011 at 1:36 AM, Kinuko Yasuda wrote:
> I would say the approach has a bloating per-page bookkeeping problem but
> not a 'leak'.
It's a reference leak: an object which remains referenced after it's no
longer needed. I'm not aware of anything standardized in the platform with
th
On Fri, Nov 18, 2011 at 1:00 PM, Glenn Maynard wrote:
> On Thu, Nov 17, 2011 at 10:47 PM, Kinuko Yasuda 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
On Thu, Nov 17, 2011 at 10:47 PM, Kinuko Yasuda 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 E
On Fri, Nov 18, 2011 at 3:55 AM, Glenn Maynard wrote:
> On Thu, Nov 17, 2011 at 1:00 PM, Kinuko Yasuda wrote:
>>
>> If we apply the current URL model to non-sandboxed cases, passing
>> URLs wouldn't imply anything about the lifetime (of the data or of
>> access rights) and the access rights would
On Thu, Nov 17, 2011 at 5:33 PM, Daniel Cheng wrote:
> Can you give an example of how you envision the write portion working?
>
Something along these lines, for example:
elem.addEventListener("drop", function(e) {
e.dataTransfer.onwritegranted = function(e) {
// Write access to the
On Wed, Nov 16, 2011 at 15:59, Eric U wrote:
> On Wed, Nov 16, 2011 at 3:55 PM, Daniel Cheng wrote:
> > Let's say I drag my pictures directory to a web app uploader. If this
> > uploader passes the DirectoryEntry to my pictures directory to a worker,
> > will it be able to read files I create a
On Thu, Nov 17, 2011 at 1:18 PM, Jonas Sicking wrote:
> I'm still not convinced that providing an API which provides
> asynchronous traversal of the files is going to lead to a better user
> experience. In all scenarios that I can think of, the page which
> received the drop is going to want to t
On Fri, Nov 18, 2011 at 3:18 AM, Jonas Sicking wrote:
> On Wed, Nov 16, 2011 at 7:09 AM, Kinuko Yasuda wrote:
>> On Wed, Nov 16, 2011 at 5:42 PM, Jonas Sicking wrote:
>>> On Tue, Nov 15, 2011 at 3:02 PM, Glenn Maynard wrote:
On Tue, Nov 15, 2011 at 5:21 PM, Jonas Sicking wrote:
>
On Thu, Nov 17, 2011 at 1:00 PM, Kinuko Yasuda wrote:
> If we apply the current URL model to non-sandboxed cases, passing
> URLs wouldn't imply anything about the lifetime (of the data or of
> access rights) and the access rights would simply expire when the
> context where the Entry was created
On Wed, Nov 16, 2011 at 7:09 AM, Kinuko Yasuda wrote:
> On Wed, Nov 16, 2011 at 5:42 PM, Jonas Sicking wrote:
>> On Tue, Nov 15, 2011 at 3:02 PM, Glenn Maynard wrote:
>>> On Tue, Nov 15, 2011 at 5:21 PM, Jonas Sicking wrote:
Adding FileEntry/DirectoryEntry seems confusing since those
(resending with re-format)
On Thu, Nov 17, 2011 at 3:21 AM, Glenn Maynard
wrote:>> As for the entry URLs I'm planning to make the URLs to the
dropped entries>> and the filesystem>> namespace (that only contains
the dropped files) expire when the page>> goes away, hoping this would
largely simplify
On Thu, Nov 17, 2011 at 3:21 AM, Glenn Maynard
wrote:> I don't think it's possible to do this correctly, because URLs
created with> toURL have no equivalent to revokeObjectURL. A
long-running page has no way> to avoid "leaking" these references
until the page exits. Adding a revoke> method for t
On Wed, Nov 16, 2011 at 6:55 PM, Daniel Cheng wrote:
> I see. I personally feel it's a little confusing to have two different
> ways to read files in DataTransfer, and now we're adding a third.
>
I don't think that's a good reason not to support this, but that said, it
may be possible to integra
On Wed, Nov 16, 2011 at 3:55 PM, Daniel Cheng wrote:
> On Wed, Nov 16, 2011 at 15:31, Glenn Maynard wrote:
>
>> On Wed, Nov 16, 2011 at 5:33 PM, Daniel Cheng wrote:
>>
>>> I'm trying to better understand the use case for DataTransfer.entries.
>>> Using the example you listed in your first post,
On Wed, Nov 16, 2011 at 2:33 PM, Daniel Cheng wrote:
> I'm trying to better understand the use case for DataTransfer.entries.
> Using the example you listed in your first post, if I dragged those folders
> into a browser, I'd expect to see File objects with the following names in
> DataTransfer.fi
On Wed, Nov 16, 2011 at 15:31, Glenn Maynard wrote:
> On Wed, Nov 16, 2011 at 5:33 PM, Daniel Cheng wrote:
>
>> I'm trying to better understand the use case for DataTransfer.entries.
>> Using the example you listed in your first post, if I dragged those folders
>> into a browser, I'd expect to s
On Wed, Nov 16, 2011 at 5:33 PM, Daniel Cheng wrote:
> I'm trying to better understand the use case for DataTransfer.entries.
> Using the example you listed in your first post, if I dragged those folders
> into a browser, I'd expect to see File objects with the following names in
> DataTransfer.f
I'm trying to better understand the use case for DataTransfer.entries.
Using the example you listed in your first post, if I dragged those folders
into a browser, I'd expect to see File objects with the following names in
DataTransfer.files:
trip/1.jpg
trip/2.jpg
trip/3.jpg
hallowee
On Wed, Nov 16, 2011 at 3:42 AM, Jonas Sicking wrote:
> > That requires a full directory traversal in advance to find all of the
> > files, though; the tree could be very large.
>
> You need to do that anyway to implement the .files attribute, no?
>
.files shouldn't recursively include all files
On Tue, Nov 15, 2011 at 9:16 PM, Glenn Maynard wrote:
> On Tue, Nov 15, 2011 at 10:58 PM, Kinuko Yasuda wrote:
>>
>> Good point, we could do this synchronously in workers!
>> I think we already have one way to convert Entry to EntrySync:
>> we can get a URL from Entry (Entry.toURL()), send the UR
On Tue, Nov 15, 2011 at 6:06 PM, Glenn Maynard wrote:
> On Tue, Nov 15, 2011 at 8:38 PM, Kinuko Yasuda wrote:
>
>> The async nature of DirectoryEntry makes the code longer,
>> but webapps can work on the files incrementally and can show
>> progress UI while enumerating. For the apps that may dea
On Wed, Nov 16, 2011 at 5:42 PM, Jonas Sicking wrote:
> On Tue, Nov 15, 2011 at 3:02 PM, Glenn Maynard wrote:
>> On Tue, Nov 15, 2011 at 5:21 PM, Jonas Sicking wrote:
>>>
>>> Adding FileEntry/DirectoryEntry seems confusing since those are
>>> generally writable in the FileSystem API spec, right?
On Wed, Nov 16, 2011 at 2:16 PM, Glenn Maynard wrote:
> On Tue, Nov 15, 2011 at 10:58 PM, Kinuko Yasuda wrote:
>> Good point, we could do this synchronously in workers!
>> I think we already have one way to convert Entry to EntrySync:
>> we can get a URL from Entry (Entry.toURL()), send the URL t
On Tue, Nov 15, 2011 at 3:02 PM, Glenn Maynard wrote:
> On Tue, Nov 15, 2011 at 5:21 PM, Jonas Sicking wrote:
>>
>> Adding FileEntry/DirectoryEntry seems confusing since those are
>> generally writable in the FileSystem API spec, right? Additionally,
>> DirectoryEntry is asynchronous, which makes
On Tue, Nov 15, 2011 at 10:58 PM, Kinuko Yasuda wrote:
> Good point, we could do this synchronously in workers!
> I think we already have one way to convert Entry to EntrySync:
> we can get a URL from Entry (Entry.toURL()), send the URL to
> the worker and get the EntrySync via resolveLocalFileS
On Wed, Nov 16, 2011 at 11:06 AM, Glenn Maynard wrote:
> On Tue, Nov 15, 2011 at 8:38 PM, Kinuko Yasuda wrote:
>>
>> The async nature of DirectoryEntry makes the code longer,
>> but webapps can work on the files incrementally and can show
>> progress UI while enumerating. For the apps that may d
On Tue, Nov 15, 2011 at 9:37 PM, Zac Spitzer wrote:
> any thoughts about minimising the security implications on this?
>
> it makes it extremely easy to jump on a machine, open a browser page,
> select a sensitive folder and upload it all to a remote server
>
It's meaningless to try to secure ag
any thoughts about minimising the security implications on this?
it makes it extremely easy to jump on a machine, open a browser page,
select a sensitive folder and upload it all to a remote server
z
On Wed, Nov 16, 2011 at 1:06 PM, Glenn Maynard wrote:
> On Tue, Nov 15, 2011 at 8:38 PM, Kinuko
On Tue, Nov 15, 2011 at 8:38 PM, Kinuko Yasuda wrote:
> The async nature of DirectoryEntry makes the code longer,
> but webapps can work on the files incrementally and can show
> progress UI while enumerating. For the apps that may deal with
> potentially huge folders providing such a scalable (
Thanks for your comments,
On Wed, Nov 16, 2011 at 8:02 AM, Glenn Maynard wrote:
> On Tue, Nov 15, 2011 at 5:21 PM, Jonas Sicking wrote:
>> Adding FileEntry/DirectoryEntry seems confusing since those are
>> generally writable in the FileSystem API spec, right? Additionally,
The spec doesn't spec
You could cheat by providing a 0 byte file "folder/nul" and define it
to not be created. On Windows (dos), such a file is used to test for
the existence of a directory, and it's illegal to create a file by
that name.
On 11/15/11, Jonas Sicking wrote:
> On Tue, Nov 15, 2011 at 1:01 AM, Kinuko Yasu
On Tue, Nov 15, 2011 at 5:21 PM, Jonas Sicking wrote:
> Adding FileEntry/DirectoryEntry seems confusing since those are
> generally writable in the FileSystem API spec, right? Additionally,
> DirectoryEntry is asynchronous, which makes enumerating the tree more
> painful.
>
> The way we were plan
On Tue, Nov 15, 2011 at 1:01 AM, Kinuko Yasuda wrote:
> Hi,
>
> We'd like to propose (and experiment in Webkit/chromium) exposing
> dropped files/folders as {File,Directory}Entry defined in FileSystem
> API [1] for better folders/files drag-and-drop support.
>
> [1] File API: Directories and Syste
Hi,
We'd like to propose (and experiment in Webkit/chromium) exposing
dropped files/folders as {File,Directory}Entry defined in FileSystem
API [1] for better folders/files drag-and-drop support.
[1] File API: Directories and System http://www.w3.org/TR/file-system-api/
Usage scenario:
Many sit
48 matches
Mail list logo
