On 10/4/13 7:48 AM, "Kyle Huey" <[email protected]<mailto:[email protected]>> wrote: Second, and related, is what happens when someone saves an image or target of a link. In both cases with "normal" URLs, there's a name component and the user agent can use that as the name of the resulting file, or suggest it if doing a Save As.... With blob URLs, there is no name, so the user agent has to make up a name. So with Firefox one gets fun names like index.gif (when saving an <img>), or bf_UK+0O.gif and y+f+wR9a.pdf (when saving the target of an anchor), and Chrome uses the opaqueString part of the URL, resulting in names like 49c122d8-0958-4dfd-ac9c-0a6245c5f91f..gif. None of those exactly brim with semantic content.
If a File object (which has a name) is used instead of a Blob I think we should treat it as if something like "Content-Disposition: filename=$file.name<http://file.name>" was specified in an HTTP request. I don't know if browsers support Content-Disposition without inline/attachment specified. This is the sort of thing that would be appropriate to put in the spec. If that's used as the suggested name for saving, that would fix my second issue (and if I could create my own File with new File(blob, name)). While I might be (probably am) missing something, I don't think there's any work around for either. Even the standard onmouseover="window.status='map.gif'" for the first doesn't work in most (all?) browsers these days. Given that, my suggestion would be to promote the name attribute from the File interface to the Blob interface, and use it (if not null) when constructing blob URLs: blob:49c122d8-0958-4dfd-ac9c-0a6245c5f91f/map.gif. When using such a blob URL to locate the Blob in memory, the user agent would ignore everything after the first slash (just as it does with #, and presumably, although the standard doesn't, but probably should, state such, ?). When saving the contents of the Blob on the filesystem, the user agent would use the Blob's name as the file name, and when doing a Save As... type operation, would suggest the same as the file name. Or, as an alternative to promoting the name attribute, scripts could add the file names (as they can add fragment identifiers (and query strings?) today) to blob URLs and the user agent would take everything between the last unescaped / and first unescaped # or ? as the file name. I don't think we want to introduce yet another way to parse URIs (which is what treating '/' as special for blob would do). It would be a change, although a small one, blob URL parsing already has to look for # (and ??), and it would be very similar to parsing other URL schemes, but yeah, it would be a change. Note that from the spec one would think I could do a new File(myBlob, myFilename), but both Firefox and Chrome throw exceptions when I do that (is that expected?), and if I use a "real" File (from a FileList), the name doesn't flow through to the blob URL and isn't used when saving. I suspect this is just not implemented yet. Could be, I'll come up with some test cases and write bugs. Thanks, Brian
