Firefox replaces colon when saving pages / PDFs, even if the filename was user-chosen in the file picker and is valid on that OS
Categories
(Firefox :: File Handling, defect)
Tracking
()
People
(Reporter: Hi-Angel, Unassigned)
References
Details
Steps to reproduce:
Was trying to overwrite a file on my system and even though the dialog asked if I want to overwrite it, I ended up with file duplicates. Upon closer inspection this turns out to be a bug in upstream Firefox.
Not reproducible in Google Chrome.
Steps to reproduce
- Open
firefox http://example.com/ - Save page to
/tmp/test:page.txt
Actual results:
The page gets saved to test page.txt (note the weird space in place of a colon)
Expected results:
It should've been saved to the filename the user asked for
|
||
Comment 1•18 days ago
|
||
Hello, thank you for the bug report!
Issue is reproducible on Firefox Nightly 128.0a1 and Firefox 127.0b1 on Ubuntu 22.
On Windows 10, the page cannot be saved with the test:page.txt name since it triggers the The file name is not valid dialog modal. On macOS 12, the page is saved as test-page.txt, replacing the colon with a hyphen.
Setting the Component to ‘File Handling’.
Setting as NEW so the developing team can have a look.
|
||
Comment 2•9 days ago
|
||
Are you typing that name manually, or is it presented to you as default file name?
Comment 1 is right that certain characters can't be used, so we must replace them, but we should sanitize the default file name.
(In reply to Marco Bonardo [:mak] from comment #2)
Are you typing that name manually, or is it presented to you as default file name?
Kind of "manually" — I just chose an existing file in the directory that I want to replace.
Comment 1 is right that certain characters can't be used, so we must replace them, but we should sanitize the default file name.
First of all, you're "sanitizing' the wrong characters: colons can be used just fine on most existing systems: Mac, Linux, Android, etc…
Second, you are not "sanitizing" anything. It would be "sanitizement" if you would refuse to save the filename. What you do instead is "breaking" the filename.
Third, what's the point of "sanitizing" if the OS will refuse to save the filename it considers invalid? It's just excess code for you and a sources of bugs like this one. You shouldn't be checking the filename for validity, OS does that for you.
Just to add more info on the usecase: colon is a very useful character, for example I save PDF files like Author: Title.pdf, and I can come up with many similar usages. Idk what people do on Windows, but I think it is fair to expect users to have files with colons on systems where that works.
|
|
||
Comment 5•9 days ago
|
||
Thank you, so you selected an existing file, and the name in the picker then was not showing a sanitized string?
The invalid characters are shared across platforms for simplicity.
I see what you mean with just letting ther OS do its thing, but in most use cases the user just wants the file saved rather than trying to figure out why it can't be saved and which characters can and can't be used. Plus there's a long story of security issues related to using certain characters, that we can't ignore.
(In reply to Marco Bonardo [:mak] from comment #5)
Thank you, so you selected an existing file, and the name in the picker then was not showing a sanitized string?
Correct, string is shown "unsanitized", i.e. I can see the : character just fine (which makes sense, because the existing file I chose has a colon in its name).
FWIW, the picker is my system's dialog, and not one made by Firefox, in case you were expecting something like that…
The invalid characters are shared across platforms for simplicity.
I see what you mean with just letting ther OS do its thing, but in most use cases the user just wants the file saved rather than trying to figure out why it can't be saved and which characters can and can't be used. Plus there's a long story of security issues related to using certain characters, that we can't ignore.
Well, granted I don't know what kind of security issues there have been, but FWIW it seems like Chrome, despite being so sensitive to security, has no problem with saving a file with a colon (and I bet all other characters prohibited on Windows, like a comma or a quote, will work too).
|
||
Comment 7•3 days ago
|
||
Neil, how hard would it be not to sanitize filenames chosen by the user in the filepicker? I would expect the OS filepicker to not allow picking filenames that are not valid on a given volume. I don't recall to what degree we considered doing this in bug 1746052 though I'm sure it's come up since then... It looks like it might already be happening in e.g. https://searchfox.org/mozilla-central/rev/23efe2c8c5b3a3182d449211ff9036fb34fe0219/toolkit/content/contentAreaUtils.js#1087-1091 but clearly not in the case described here...
|
|
||
Comment 8•3 days ago
•
|
||
(I expect bug 934084 which was added to the "See also" field might be WFM right now... but perhaps some sanitization should happen earlier, and is currently happening later?)
|
|
||
Comment 9•3 days ago
|
||
the ALLOW_INVALID_FILENAMES flag is apparently only used for the extension https://searchfox.org/mozilla-central/rev/23efe2c8c5b3a3182d449211ff9036fb34fe0219/uriloader/exthandler/nsExternalHelperAppService.cpp#3687-3703
|
||
Comment 10•1 day ago
|
||
Yes, we would just need to remove or modify the line at https://searchfox.org/mozilla-central/rev/23efe2c8c5b3a3182d449211ff9036fb34fe0219/toolkit/content/contentAreaUtils.js#733 to not sanitize the filename selected from the filepicker.
That line has been there since this was first implemented so now that we have more thorough filename sanitization, we could probably remove that line and assume that whatever the user types in is what was desired.
Description
•