Drag and Drop - setData with Download URL bypasses service worker. |
||||||
Issue descriptionI have a demo I am building that enable the user to drag a HTML element out of the browser and on to the desktop. The data for the drop operation is generated entirely in the client (I have issues with blobs for another bug). I have a ServiceWorker that generates the data for the download by intercepting the request to a well known url, when setting DownloadURL on the dataTransfer object it doesn't work, a file is sent to the drop area but it's 0 bytes because the request doesn't go through the service worker. DEMO: https://pebble-hook.glitch.me/ DEMO code: https://glitch.com/edit/#!/pebble-hook?path=public/index.html:20:11 My expectation is that the SW would process the response and it to save the result to where the file was dropped. Dropping a file that is on the server works.
,
Jul 12 2017
,
Jul 12 2017
issue 468227 appears related - "downloads" aren't hooked up to SWs so far as I can tell.
,
Jul 12 2017
DownloadURL's behavior isn't defined anywhere. But the spec for <a download> has the fetch invocation here: https://html.spec.whatwg.org/multipage/links.html#downloading-hyperlinks Initiator is "download", no special service-worker mode is specified (so "all"), so following through these: https://fetch.spec.whatwg.org/#concept-fetch https://fetch.spec.whatwg.org/#concept-main-fetch https://fetch.spec.whatwg.org/#http-fetch ... so I'd expect the SW to get "handle fetch" invoked for <a download> which is probably the closest thing to DownloadURL. falken@ - can you triage?
,
Jul 13 2017
I think we should trigger the FetchEvent in SW same as <a download>.
I was surprised that there is no spec about dataTransfer.setData('DownloadURL', '').
https://html.spec.whatwg.org/multipage/dnd.html#dom-datatransfer-setdata
,
Jul 13 2017
,
Jul 6
DownloadURL is both non-standard and an invalid MIME media type. The standard media type for this form of URI interchange encoding is text/uri-list, defined in RFC 2483.
,
Jul 6
setData doesn't require it to be a mime type, it can be any string, but it would be nice if we had a standard way of defining what could constitute some that is meant to be download when a drop event occurs in the OS. I don't think the mime-type is sufficient, really it should be what is contained on the .files object, and that can be downloaded by the web application directly and put on to the dataTransfer object.
,
Jul 6
I'm honestly not sure where DownloadURL is specified. If it were up to me, I would prefer to remove it entirely, but I think it's fairly widely used at this point. DownloadURL today is handled entirely browser side, so making this work would probably be a somewhat large investment.
,
Jul 6
It's not specified, that's part certainly part of the issue. It was used first in gmail iirc, and now it's the only way to get files out of the browser and back into the host. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by dcheng@chromium.org
, Jul 12 2017