Bug 1651800 Comment 7 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

I'm sorry, it was not my intention to say whether what you do is right or wrong, I just meant there are so many use-cases that we may have to make a choice to what we want and what not.

(In reply to Aleph1 from comment #6)
> Seriously, there isn't any other program that pops up a save dialog and then saves *silently* to a different filename than what it's told.

I don't think that we show a name and then save to another one, apart from the string you are typing of course, we can't change that while you're typing. Please let me know if somewhere (a download dialog or panel) we show the unstripped string.

> By all means go ahead and sanitize download names *when there are security implications*, but if the save position is otherwise valid it shouldn't be the browser's business to do different from what it's told to. 

Well, there is some security implications if you can hide the file extension with a large amount of spaces, I just tried and it's totally doable on Windows.
But there are also usability problems when the file name can easily be wrongly presented to the user in html, because naturally it compresses spaces.
Additionally for most users it is really hard to distinguish from 2 spaces on, is it 4 or 5? is that meaning information at that point? We should not be optimizing for edge-cases in general.

> BTW the browser shouldn't replace runs of spaces even when it's configured to not ask where to save IMO. Let's suppose someone uploads two files e.g. to Dropbox, named "**File A.txt**" and "**File  A.txt**". When then downloaded with Firefox, those two files become "**File A.txt**" and "**File A (2).txt**" ... Don't think that's the behavior a user would reasonably expect from their browser.

Yes, I'd expect that. The space is not adding useful information, and may well hide a bug that the uploader didn't notice.

> footnote 1: tried using non-breaking spaces (alt+0160 on Windows) and they're collapsed to a single one just like normal spaces. Web pages don't replace runs of them, as you surely know.

True, but visually for a user it doesn't make a difference, it may still be confusing.
I'm sorry, it was not my intention to say whether your use case is right or wrong, I just meant there are so many use-cases that we may have to make a choice to what we want and what not.

(In reply to Aleph1 from comment #6)
> Seriously, there isn't any other program that pops up a save dialog and then saves *silently* to a different filename than what it's told.

I don't think that we show a name and then save to another one, apart from the string you are typing of course, we can't change that while you're typing. Please let me know if somewhere (a download dialog or panel) we show the unstripped string.

> By all means go ahead and sanitize download names *when there are security implications*, but if the save position is otherwise valid it shouldn't be the browser's business to do different from what it's told to. 

Well, there is some security implications if you can hide the file extension with a large amount of spaces, I just tried and it's totally doable on Windows.
But there are also usability problems when the file name can easily be wrongly presented to the user in html, because naturally it compresses spaces.
Additionally for most users it is really hard to distinguish from 2 spaces on, is it 4 or 5? is that meaning information at that point? We should not be optimizing for edge-cases in general.

> BTW the browser shouldn't replace runs of spaces even when it's configured to not ask where to save IMO. Let's suppose someone uploads two files e.g. to Dropbox, named "**File A.txt**" and "**File  A.txt**". When then downloaded with Firefox, those two files become "**File A.txt**" and "**File A (2).txt**" ... Don't think that's the behavior a user would reasonably expect from their browser.

Yes, I'd expect that. The space is not adding useful information, and may well hide a bug that the uploader didn't notice.

> footnote 1: tried using non-breaking spaces (alt+0160 on Windows) and they're collapsed to a single one just like normal spaces. Web pages don't replace runs of them, as you surely know.

True, but visually for a user it doesn't make a difference, it may still be confusing.

Back to Bug 1651800 Comment 7