I'm not sure how we'd distinguish a space generated from replacing an invalid char, from a normal space (without ugly double replacements). Even if we'd first check if there are invalid chars, there could still be multiple spaces too. So the question is pretty much whether we should compress whitespaces at all. I think the most common case is making the file name more readable and usable to the user, rather than supporting exotic use-cases, like the example you pointed out, and compressing whitespaces goes that direction. Other examples are for example posting a filename with multiple spaces on the Web compresses them into a single one (note how comment 0 itself had to specify the name contains 2 spaces); or typing into a shell, it's hard to distinguish the number of consecutive spaces to type. I must note that to fix this specific case we could add an options argument to sanitize, like { compressWhitespaces: false } and WebExt could use that, while the rest of the code will keep compressing. I don't have such strong feelings anyway, this is my opinion but if others think differently I'm fine to revert.
Bug 1637973 Comment 6 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 not sure how we'd distinguish a space generated from replacing an invalid char, from a normal space (without ugly double replacements). Even if we'd first check if there are invalid chars, there could still be multiple spaces too. So the question is pretty much whether we should compress whitespaces at all. I think the most common case is making the file name more readable and usable to the user, rather than supporting exotic use-cases, like the example you pointed out, and compressing whitespaces goes that direction. For example posting a filename with multiple spaces on the Web compresses them into a single one (note how comment 0 itself had to specify the name contains 2 spaces); or typing into a shell, it's hard to distinguish the number of consecutive spaces to type. I must note that to fix this specific case we could add an options argument to sanitize, like { compressWhitespaces: false } and WebExt could use that, while the rest of the code will keep compressing. I don't have such strong feelings anyway, this is my opinion but if others think differently I'm fine to revert.