Should downloadWillBegin suggestedFilename match actual filename on local filesystem?

[juliandescottes]

I'm not sure I understand how suggestedFilename is intended to be defined.

Based on https://html.spec.whatwg.org/#getting-the-suggested-filename , it says (step 12):

Let filename be set to the user's preferred filename or to a filename selected by the user agent

Which means in case the browser prompts the user to select a location and filename, it should incorporate it.

It also says (step 14):

Adjust filename to be suitable for the local file system.

When downloading a file which has a name already used in the filesystem, both Firefox and Chrome will add a counter (1), (2) before the extension. For instance click several times on the link in https://bug1874365.bmoattachments.org/attachment.cgi?id=9506609

Does this mean the (1) etc... is part of the suggested filename? In a sense it was adapted to the local file system by adding some unique identifier to it.

From #840 , the motivation behind adding suggestedFilename was to allow users to perform cleanup, so it seems to me we should be as faithful as possible to the name used on the filesystem?

I am asking because right now the wdspec test saves using the same filename several times, and I can actually see that the second time it adds a (1) in the filename, but Chrome doesn't report it in the suggested filename.

Possibly a bug in Chrome's implementation, but the HTML spec is a bit vague on this topic. cc @sadym-chromium

[juliandescottes]

Notes from the working group minutes:

18:22 jdescottes: when you download the link several times, it adds a counter, however Chrome does not expose that real filename. Should we expose the real filename? Are we OK with exposing the real filename?
18:22 q+
18:22 * Zakim sees whimboo on the speaker queue
18:22 sadym: it probably a bug in Chrome, but IDK if we can fix it
18:22 ack whimboo
18:22 * Zakim sees no one on the speaker queue
18:23 whimboo: we can expose the name at the moment the download finished
18:23 we should know the filename by that time
18:24 q+
18:24 * Zakim sees jdescottes on the speaker queue
18:24 ack jdescottes
18:24 * Zakim sees no one on the speaker queue
18:24 jdescottes: from Firefox point of view, we have the information early. The question is if we want to send that information earlier. From our side both approaches are fine.
18:25 I'm going to update WPT tests to avoid running into this issue

[juliandescottes]

Another thing to note is that browsingContext.downloadEnd contains a downloadedFilepath in case the download was successful.

The hook for this event doesn't seem defined anywhere though (looked in html and fetch spec) so it's a bit hard to know what this path is going to be set to, but this makes me wonder if suggestedFilename is really intended to be the actual filename created on the filesystem. If someone wants to collect the information for cleanup, downloadedFilepath seems like a better fit (because with suggestedFilename, you still need to figure out the rest of the path...).

[whimboo]

If someone wants to collect the information for cleanup, downloadedFilepath seems like a better fit (because with suggestedFilename, you still need to figure out the rest of the path...).

That actually reflects what I mentioned during the last W3C meeting. If the filename can change than it's indeed not helpful to use.

[juliandescottes]

If the filename can change than it's indeed not helpful to use.

From reading the HTML spec, I'm not sure it can change, but the actual download is not very clearly described. The main thing is that this is just a filename, and not a path, so it makes it a bit more painful to use anyway. Not sure if we want to keep it.

[sadym-chromium]

Does this mean the (1) etc... is part of the suggested filename? In a sense it was adapted to the local file system by adding some unique identifier to it.

The suggestedFilename is the result of getting the suggested filename and intended to check if the headers and attributes like download are properly setup.

So I propose we keep it.