[whatwg] Drag-and-drop feedback

[Charles Pritchard]

On 11/1/2010 6:03 PM, Ian Hickson wrote:
> On Thu, 26 Aug 2010, Charles Pritchard wrote:
>> On 8/25/2010 2:02 PM, Ian Hickson wrote:
>>> On Mon, 2 Aug 2010, Charles Pritchard wrote:
>>>>> [ UAs can use<input type=file>   to let the user enter remote URLs ]
>>>> When a user through selection, click+drag or manual entry of a URL
>>>> should the browser still submit an Origin request header? It seems
>>>> that CORS doesn't come into effect here -- but at the same time,
>>>> it'd be handy for logging purposes and added security.
>>> I don't think there'd be an origin, but that's rather up to the user
>>> agent. (In this case it's acting on behalf of the user, not the page,
>>> so I don't think it makes sense to give the page's origin.)
>> Sounds like an implementer would not include a Referer header, either.
> Possibly.

Currently, this seems to be implemented by the OS:
Vista downloads a URL to the temporary files directory, then passes it 
to the browser.
No cookies, or other credentials are sent with the fetch, as it is an 
OS-level fetch.

Entering a remote URL does not seem to function in OS X as there is no 
place on the file upload screen to enter a URL.

Is this something we want to leave undefined? As the <input type="file"> 
widget typically
routes directly to OS-level file management, I don't think there's a 
simple solution to bringing
more control to the browser.

>> Continuing on with tweaking URLs to work with with the File API:
>>
>> Chrome has gone ahead with their setData proposal, enhancing the
>> event.dataTransfer object so that users may drag a file from within the
>> browser onto their desktop.
>>
>> The extension uses setData with a key of DownloadURL and a value
>> including a mime type, file descriptor and URI.
>>
>> I'd like this interface to work within ondrop; if getData(DownloadURL)
>> is set, then a FileList would be returned in event.dataTransfer.files,
>> much like it is when users drag files from their desktop into the
>> browser.
>>
>> This would of course require Origin checks; whereas dragging onto the
>> desktop does not require an Origin check.
> I'm not quite sure I follow what you are proposing. However, in a future
> version of this API we should definitely add a "promise"-like feature that
> lets you specify drag data without having it already downloaded, so that
> when the user drops the data somewhere, the browser can then ask the JS
> for the data. I'm not sure using setData('DownloadURL') is a good way to
> do it; that just seems to add more hacks to an already pretty hacky API.
The DataTransferItem proposal is heading in this direction.
Currently, a file collection ".files", works with the File API and 
XmlHttpRequest.
Drag+drop from the desktop returns file objects.

I'm proposing we explore methods to enable drag+drop from within the 
browser to return file objects.

The FileSystem API is a resource: we can now build a file from within 
standard APIs.
Until that point, we could only use the BlobBuilder semantics.

The proposal DataTransferItem.add(fileData)
pretty much takes care of the request (when used with a working/complete 
FileSystem API).

We still need a promise-like feature, as you've pointed out.

....

On a side note -- I've been having a lot of issue with building blobs:

Are there currently semantics in place to distinguish a DOMString from 
binary data?

At present, I can only think of Typed Arrays from the WebGL-related specs.

Currently, when I try to build a Blob using binary data, I end up with a 
UTF-8 escaped DOM String.

I'm still forced to run an XHR request, to grab binary data for an image 
(one already loaded by the browser),
so that I can store that image data in local storage. I then use a 
js-based base64 encoder, as browser encoders are expecting
a DOMString and throw errors on binary (per specs).

This would be solved in part, via FileSystem/File APIs, but they're also 
expecting DOMString.
I expect it's meant to be solved by adding Blob support directly to XHR.