Thanks for the feedback.
On Fri, Sep 14, 2012 at 6:58 AM, Ian Hickson i...@hixie.ch 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 input type=file multiple or
drag-and-drop
On Thu, 13 Sep 2012 23:58:42 +0200, Ian Hickson i...@hixie.ch 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
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 input type=file multiple or
drag-and-drop feature, but the current solution does not provide clean
solution for cases with folders,
Apologies for my late response.
On Tue, Apr 10, 2012 at 7:33 AM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Apr 9, 2012 at 3:35 AM, Kinuko Yasuda kin...@chromium.org wrote:
I don't think we should do this. The change would be invasive and could
delay firing a drop event indefinitely if
uOn Fri, Apr 6, 2012 at 10:37 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Apr 5, 2012 at 11:42 PM, Kinuko Yasuda kin...@chromium.orgwrote:
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
On Thu, Apr 5, 2012 at 8:52 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Apr 4, 2012 at 11:36 PM, Kinuko Yasuda kin...@chromium.org 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:
On Mon, Apr 9, 2012 at 3:35 AM, Kinuko Yasuda kin...@chromium.org 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
On Thu, Apr 5, 2012 at 11:42 PM, Kinuko Yasuda kin...@chromium.org 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
On Wed, Apr 4, 2012 at 9:36 PM, Kinuko Yasuda kin...@chromium.org 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
On Fri, Apr 6, 2012 at 12:32 AM, Eric U er...@google.com wrote:
On Wed, Apr 4, 2012 at 9:36 PM, Kinuko Yasuda kin...@chromium.org 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:
On Wed, Apr 4, 2012 at 11:36 PM, Kinuko Yasuda kin...@chromium.org 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
On Fri, Apr 6, 2012 at 12:52 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Apr 4, 2012 at 11:36 PM, Kinuko Yasuda kin...@chromium.orgwrote:
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:
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
On Thu, Nov 17, 2011 at 3:21 AM, Glenn Maynard gl...@zewt.org
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
(resending with re-format)
On Thu, Nov 17, 2011 at 3:21 AM, Glenn Maynard gl...@zewt.org
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
On Wed, Nov 16, 2011 at 7:09 AM, Kinuko Yasuda kin...@chromium.org wrote:
On Wed, Nov 16, 2011 at 5:42 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Nov 15, 2011 at 3:02 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Nov 15, 2011 at 5:21 PM, Jonas Sicking jo...@sicking.cc wrote:
Adding
On Thu, Nov 17, 2011 at 1:00 PM, Kinuko Yasuda kin...@chromium.org 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
On Fri, Nov 18, 2011 at 3:18 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Nov 16, 2011 at 7:09 AM, Kinuko Yasuda kin...@chromium.org wrote:
On Wed, Nov 16, 2011 at 5:42 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Nov 15, 2011 at 3:02 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue,
On Thu, Nov 17, 2011 at 1:18 PM, Jonas Sicking jo...@sicking.cc 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
On Wed, Nov 16, 2011 at 15:59, Eric U er...@google.com wrote:
On Wed, Nov 16, 2011 at 3:55 PM, Daniel Cheng dch...@chromium.org 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
On Thu, Nov 17, 2011 at 5:33 PM, Daniel Cheng dch...@google.com 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
On Fri, Nov 18, 2011 at 3:55 AM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Nov 17, 2011 at 1:00 PM, Kinuko Yasuda kin...@chromium.org 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)
On Thu, Nov 17, 2011 at 10:47 PM, Kinuko Yasuda kin...@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
On Tue, Nov 15, 2011 at 3:02 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Nov 15, 2011 at 5:21 PM, Jonas Sicking jo...@sicking.cc wrote:
Adding FileEntry/DirectoryEntry seems confusing since those are
generally writable in the FileSystem API spec, right? Additionally,
DirectoryEntry is
On Wed, Nov 16, 2011 at 2:16 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Nov 15, 2011 at 10:58 PM, Kinuko Yasuda kin...@chromium.org 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
On Wed, Nov 16, 2011 at 5:42 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Nov 15, 2011 at 3:02 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Nov 15, 2011 at 5:21 PM, Jonas Sicking jo...@sicking.cc wrote:
Adding FileEntry/DirectoryEntry seems confusing since those are
generally writable
On Tue, Nov 15, 2011 at 6:06 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Nov 15, 2011 at 8:38 PM, Kinuko Yasuda kin...@chromium.org 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.
On Tue, Nov 15, 2011 at 9:16 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Nov 15, 2011 at 10:58 PM, Kinuko Yasuda kin...@chromium.org 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
On Wed, Nov 16, 2011 at 3:42 AM, Jonas Sicking jo...@sicking.cc 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
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
On Wed, Nov 16, 2011 at 5:33 PM, Daniel Cheng dch...@chromium.org 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
On Wed, Nov 16, 2011 at 15:31, Glenn Maynard gl...@zewt.org wrote:
On Wed, Nov 16, 2011 at 5:33 PM, Daniel Cheng dch...@chromium.org 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
On Wed, Nov 16, 2011 at 2:33 PM, Daniel Cheng dch...@chromium.org 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
On Wed, Nov 16, 2011 at 3:55 PM, Daniel Cheng dch...@chromium.org wrote:
On Wed, Nov 16, 2011 at 15:31, Glenn Maynard gl...@zewt.org wrote:
On Wed, Nov 16, 2011 at 5:33 PM, Daniel Cheng dch...@chromium.org wrote:
I'm trying to better understand the use case for DataTransfer.entries.
Using
On Wed, Nov 16, 2011 at 6:55 PM, Daniel Cheng dch...@chromium.org 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
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
On Tue, Nov 15, 2011 at 5:21 PM, Jonas Sicking jo...@sicking.cc 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
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 jo...@sicking.cc wrote:
On Tue, Nov 15, 2011 at 1:01
Thanks for your comments,
On Wed, Nov 16, 2011 at 8:02 AM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Nov 15, 2011 at 5:21 PM, Jonas Sicking jo...@sicking.cc wrote:
Adding FileEntry/DirectoryEntry seems confusing since those are
generally writable in the FileSystem API spec, right?
On Tue, Nov 15, 2011 at 8:38 PM, Kinuko Yasuda kin...@chromium.org 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
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 gl...@zewt.org wrote:
On Tue, Nov 15, 2011 at
On Tue, Nov 15, 2011 at 9:37 PM, Zac Spitzer zac.spit...@gmail.com 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
On Wed, Nov 16, 2011 at 11:06 AM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Nov 15, 2011 at 8:38 PM, Kinuko Yasuda kin...@chromium.org 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.
On Tue, Nov 15, 2011 at 10:58 PM, Kinuko Yasuda kin...@chromium.org 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
44 matches
Mail list logo
