Re: [request] Download Event for HTMLAnchorElement
On 3/25/14 12:14 PM, Si Robertson retromodu...@gmail.com wrote: When a user decides to save a file that they have been working on in an application, the file data is typically a temporary serialized version of the file's state/model. Native applications will write the data directly to disk using an output stream but that isn't possible for a web application to do, so web applications need to generate the data in memory, as a blob, before presenting it to the user for downloading. After the download has been completed the data can be released from memory. If Glenn is correct and the data can be released/revoked as soon as the download begins, then that makes things a lot easier to deal with. No one wants huge blobs of redundant data floating around in memory for no reason, so manually revoking object URLs (which is something Mozilla et al recommends) is important. That's one use case, but another is where the blob URL is the href in a static anchor (i.e. not one generated solely to allow saving some data that will be removed after it's used) and you want it to be downloadable multiple times. In that case auto-revoking upon download doesn't work. Brian PS I've modified my message composition settings so I'm hoping this will look better in the archives, but Mac Outlook doesn't offer a lot of configurability around replies, so it might not.
Re: [request] Download Event for HTMLAnchorElement
On Tue, Mar 25, 2014 at 1:10 AM, Si Robertson retromodu...@gmail.com wrote: Ideally, the File API would provide a way for users to save a file, and I'm surprised this is still an issue. Writing a file to a user selected location is no less secure than allowing a user to download a file with an anchor. Well, for one we have UI, for the other we currently do not. That makes it harder. -- http://annevankesteren.nl/
Re: [request] Download Event for HTMLAnchorElement
* Si Robertson wrote: The problem that this new event would solve is this - when using a temporary object URL (blob) for the file data, e.g. programmatically generated content, there is currently no way of knowing when that file data has been written to disk, therefore there is no reliable way of knowing when it is safe to revoke the object URL in order to release resources. That something has been written to disk does not make destryoing data safe. It is not unsual, for instance, to expect that data can be saved more than once, and invalidating such expectations can lead to catas- trophic data loss. I think release-after-first-save-action is not a pattern to be encouraged, at least not without secondary safeguards. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [request] Download Event for HTMLAnchorElement
On Mon, Mar 24, 2014 at 8:10 PM, Si Robertson retromodu...@gmail.comwrote: Allowing users to save/download a runtime-generated file with the use of object URLs and the anchor download attribute is the only viable way of doing things at the moment. Bouncing the file through a server isn't acceptable for web applications that are supposed to act like native apps. You didn't quote anything, so I'm not sure what this is a reply to, but I don't think anybody mentioned bouncing the file through a server. Ideally, the File API would provide a way for users to save a file, and I'm surprised this is still an issue. Writing a file to a user selected location is no less secure than allowing a user to download a file with an anchor. As I mentioned earlier, the FileSaver API is defined but it hasn't been implemented as far as I know, and it wouldn't necessarily actually solve this problem. -- Glenn Maynard
Re: [request] Download Event for HTMLAnchorElement
* Bjoern Hoehrmann write: That something has been written to disk does not make destryoing data safe. It is not unsual, for instance, to expect that data can be saved more than once, and invalidating such expectations can lead to catas- trophic data loss. I think release-after-first-save-action is not a pattern to be encouraged, at least not without secondary safeguards. There's no need to be so dramatic :-) When a user decides to save a file that they have been working on in an application, the file data is typically a temporary serialized version of the file's state/model. Native applications will write the data directly to disk using an output stream but that isn't possible for a web application to do, so web applications need to generate the data in memory, as a blob, before presenting it to the user for downloading. After the download has been completed the data can be released from memory. If Glenn is correct and the data can be released/revoked as soon as the download begins, then that makes things a lot easier to deal with. No one wants huge blobs of redundant data floating around in memory for no reason, so manually revoking object URLs (which is something Mozilla et al recommends) is important.
Re: [request] Download Event for HTMLAnchorElement
On 3/23/14 5:30 PM, Si Robertson retromodu...@gmail.com wrote: Hi guys, This mailing list was suggested to me by one of the Chromium developers, so I apologize in advance if this mailing list is not appropriate for this request/proposal. In a nutshell, I am asking for a download event to be dispatched from anchor elements that support the download attribute. a href=blob:... type=... download=... ondownload=release(this)download/a The problem that this new event would solve is this - when using a temporary object URL (blob) for the file data, e.g. programmatically generated content, there is currently no way of knowing when that file data has been written to disk, therefore there is no reliable way of knowing when it is safe to revoke the object URL in order to release resources. Thanks for your time. Regards, Si Robertson Is the download generating a temporary copy of the blob to do the download? If so, it seems it should be up to the browser to handle cleaning it up, not the developer. If referring to the blob referenced by the href, won't releasing it after the first download prevent it from being downloaded again? Maybe an edge case, but not one I would want to preclude. Also, if the browser doesn't know when the file's been downloaded, how does it know when to fire the ondownload event? Probably newby questions, but I'm working on some code that does exactly this, programmatically generates anchors referencing programmatically generated blobs, so I want to understand how they're handled and what requirements are put on me to make sure things are cleaned up as necessary. Thanks, Brian
Re: [request] Download Event for HTMLAnchorElement
If a developer creates an object URL, e.g. theFile =
URL.createObjectURL(theData), then it's the developer's responsibility to
revoke that object URL. Assigning theFile to an anchor href so the data can
be downloaded doesn't create a copy of data.
The web browser will definitely know when the data has been written to
disk, the problem is the developer won't know when the data has been
written to disk, so it's currently impossible to revoke the object URL
(release the data from memory) at a safe time. When the anchor is clicked
you could create a timer and revoke the object URL after a certain number
of seconds have elapsed but you will still be taking a shot in dark.
Ideally we need to be able to do something like this ...
anchor.ondownload = function(e) {
URL.revokeObjectURL(theFile);
}
A simplified example of course, but it demonstrates what's needed.
// Si
On 24 March 2014 18:51, Brian Matthews (brmatthe) brmat...@cisco.comwrote:
On 3/23/14 5:30 PM, Si Robertson retromodu...@gmail.com wrote:
Hi guys,
This mailing list was suggested to me by one of the Chromium developers,
so I apologize in advance if this mailing list is not appropriate for
this request/proposal.
In a nutshell, I am asking for a download event to be dispatched from
anchor elements that support the download attribute.
a href=blob:... type=... download=...
ondownload=release(this)download/a
The problem that this new event would solve is this - when using a
temporary object URL (blob) for the file data, e.g. programmatically
generated content, there is currently no way of knowing when that file
data has been written to disk, therefore there
is no reliable way of knowing when it is safe to revoke the object URL
in order to release resources.
Thanks for your time.
Regards,
Si Robertson
Is the download generating a temporary copy of the blob to do the
download? If so, it seems it should be up to the browser to handle
cleaning it up, not the developer. If referring to the blob referenced by
the href, won't releasing it after the first download prevent it from
being downloaded again? Maybe an edge case, but not one I would want to
preclude. Also, if the browser doesn't know when the file's been
downloaded, how does it know when to fire the ondownload event?
Probably newby questions, but I'm working on some code that does exactly
this, programmatically generates anchors referencing programmatically
generated blobs, so I want to understand how they're handled and what
requirements are put on me to make sure things are cleaned up as
necessary.
Thanks,
Brian
Re: [request] Download Event for HTMLAnchorElement
On Mon, Mar 24, 2014 at 2:45 PM, Si Robertson retromodu...@gmail.com wrote: If a developer creates an object URL, e.g. theFile = URL.createObjectURL(theData), then it's the developer's responsibility to revoke that object URL. Assigning theFile to an anchor href so the data can be downloaded doesn't create a copy of data. Requiring the user to revoke blob URLs is manual resource management, which is inherently brittle in JS. The eventual solution should be auto-revoke URLs, which makes it the browser's job to revoke the URL. We should make that work fully, not add more events to allow manual revocation. Autorevoke URLs are in, but the mechanism for the browser to see a.href = myAutoRevokeObjectURL and keep the URL alive correctly is still being worked on (https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765). That said: On Mon, Mar 24, 2014 at 2:45 PM, Si Robertson retromodu...@gmail.comwrote: The web browser will definitely know when the data has been written to disk, the problem is the developer won't know when the data has been written to disk, so it's currently impossible to revoke the object URL (release the data from memory) at a safe time. When the anchor is clicked you could create a timer and revoke the object URL after a certain number of seconds have elapsed but you will still be taking a shot in dark. If you don't care about the user clicking the link more than once, it should always be safe to release the object URL immediately after the click event has completed. If the browser has begun downloading (copying to disk) the blob, that operation should be unaffected by you releasing the object URL. You would just need to use a zero-second timer, so that you release it after the click event has completed and not while it's being dispatched. (If you do something like this, be sure to hide the download link and at least replace it with a Download in progress, or better a Click here to restart download to regenerate the blob, so you don't leave a broken anchor on the page.) This may not work in browsers yet, and this may not be well-defined in the spec. If it's not, I'm guessing it'll be fixed as part of https://www.w3.org/Bugs/Public/show_bug.cgi?id=24338. -- Glenn Maynard
Re: [request] Download Event for HTMLAnchorElement
On 3/24/14 1:16 PM, Glenn Maynard gl...@zewt.orgmailto:gl...@zewt.org wrote: On Mon, Mar 24, 2014 at 2:45 PM, Si Robertson retromodu...@gmail.commailto:retromodu...@gmail.com wrote: The web browser will definitely know when the data has been written to disk, the problem is the developer won't know when the data has been written to disk, so it's currently impossible to revoke the object URL (release the data from memory) at a safe time. When the anchor is clicked you could create a timer and revoke the object URL after a certain number of seconds have elapsed but you will still be taking a shot in dark. If you don't care about the user clicking the link more than once, it should always be safe to release the object URL immediately after the click event has completed. If the browser has begun downloading (copying to disk) the blob, that operation should be unaffected by you releasing the object URL. You would just need to use a zero-second timer, so that you release it after the click event has completed and not while it's being dispatched. (If you do something like this, be sure to hide the download link and at least replace it with a Download in progress, or better a Click here to restart download to regenerate the blob, so you don't leave a broken anchor on the page.) This may not work in browsers yet, and this may not be well-defined in the spec. If it's not, I'm guessing it'll be fixed as part of https://www.w3.org/Bugs/Public/show_bug.cgi?id=24338. But I do care about the user clicking more than once. I know I do that occasionally, and would be annoyed at a site that wouldn't let me, and I don't want to annoy my users in that way. Presumably in that case I want the URL and blob to stay around until the page goes away, which I'd guess is how it would work? Brian
Re: [request] Download Event for HTMLAnchorElement
(Can you turn off the Outlook-style indentation quoting? It makes the archives unreadable: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0738.html, and doesn't mix well with regular quoting.) On Mon, Mar 24, 2014 at 5:24 PM, Brian Matthews (brmatthe) brmat...@cisco.com wrote: But I do care about the user clicking more than once. I know I do that occasionally, and would be annoyed at a site that wouldn't let me, and I don't want to annoy my users in that way. Presumably in that case I want the URL and blob to stay around until the page goes away, which I'd guess is how it would work? Right, if you want the link to be reusable, then you can't revoke the blob URL. Even if the download completes, the user might still click it again. FileSaver avoids the need for blob URLs entirely, but never got much momentum. It might not really solve this problem anyway, since you'd still need to have a synchronous reference to the Blob for it to work. If you had to do an async request in onclick to create the Blob before you could start the FileSaver, browsers would probably treat it as an unsolicited popup and disallow it anyway. http://dev.w3.org/2009/dap/file-system/file-writer.html#the-filesaver-interface If you're actually generating a large blob of data and allowing the user to save it to disk (for example, gunzipping a 500 MB file and saving the uncompressed file to disk), neither of these are very good, since they both mean writing the big data to a Blob first (probably going to disk), then copying that to the user file when he saves it. I haven't been following the stream API much, but I assume this is something it would help address. -- Glenn Maynard
Re: [request] Download Event for HTMLAnchorElement
Allowing users to save/download a runtime-generated file with the use of object URLs and the anchor download attribute is the only viable way of doing things at the moment. Bouncing the file through a server isn't acceptable for web applications that are supposed to act like native apps. Ideally, the File API would provide a way for users to save a file, and I'm surprised this is still an issue. Writing a file to a user selected location is no less secure than allowing a user to download a file with an anchor. // Si
