1638086 - local directory listing bug, multiple spaces are collapsed in local filenames

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Jelle Geerts]

Attachment: filename-multiple-spaces-collapsed.png

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

Steps:

1. Create a local directory like /tmp/example_dir
2. Create a file with a name such as 'foo bar' (lots of spaces), or even one that ends with multiple spaces, such as 'salad dressing '.
3. Visit file:///tmp/example_dir in Firefox.
4. Notice that the filenames shown are 'foo bar' (spaces collapsed) and 'salad dressing'.

This is purely a visual bug. The engine is correctly collapsing spaces.

Possible CSS solution (just thinking out loud here):

I'm guessing that the problem can be fixed by using 'white-space: pre-wrap;' in 'dirListing.css'.

(Currently 'white-space' isn't being used.)

Thinking about what value to use for 'white-space':

I guess both 'break-spaces' and 'pre-wrap' seem like good candidates.
But, I guess 'pre-wrap' is a better choice than 'break-spaces' because the latter can lead to a filename being able to take up more than 1 line if the filename ends with multiple spaces. (In that case, the filenames takes up 2 lines, but the 2nd line is empty and the 1st line ends with the ellipsis ... characters, so that would look odd with the 2nd line being empty after the ellipsis characters.)
Hence 'pre-wrap' is probably a better choice. When using 'pre-wrap', filenames that end with multiple spaces take up only 1 line, and multiple spaces located elsewhere (not at the end) are displayed correctly.

Actual results:

Multiple (sequential) spaces in filenames are collapsed to single spaces. Thus, filenames like 'foo bar' are shown as 'foo bar'.

Expected results:

The filename should be shown as it really is.

Comment 1

[Jelle Geerts]

Funny, the spaces in the example filenames in the bug report are shown collapsed as well. Trying to use grave accents (for Markdown inline code) doesn't appear to help, either. But you get the point.

Comment 2

[Alice0775 White]

last good: 2007-08-17-05
first bad: 2007-08-17-23

Comment 3

[:Gijs (he/him)]

Attachment: Bug 1638086 - show multiple subsequent spaces in file listings, r?valentin

Comment 4

[:Gijs (he/him)]

Thanks for the report!

(In reply to Jelle Geerts from comment #0)

Possible CSS solution (just thinking out loud here):

I'm guessing that the problem can be fixed by using 'white-space: pre-wrap;' in 'dirListing.css'.

(Currently 'white-space' isn't being used.)

Thinking about what value to use for 'white-space':

I guess both 'break-spaces' and 'pre-wrap' seem like good candidates.
But, I guess 'pre-wrap' is a better choice than 'break-spaces' because the latter can lead to a filename being able to take up more than 1 line if the filename ends with multiple spaces. (In that case, the filenames takes up 2 lines, but the 2nd line is empty and the 1st line ends with the ellipsis ... characters, so that would look odd with the 2nd line being empty after the ellipsis characters.)
Hence 'pre-wrap' is probably a better choice. When using 'pre-wrap', filenames that end with multiple spaces take up only 1 line, and multiple spaces located elsewhere (not at the end) are displayed correctly.

I put up a patch to use white-space: pre. Does that sound OK? I'm not sure why we'd use pre-wrap if we don't want the content to wrap, but maybe I'm missing some subtlety...

Comment 5

[Jelle Geerts]

I think I arrived at that by testing crazy things like filenames with newlines in them.
For example 'foo<LF>bar<SP><SP><and_so_on>' where <LF> is an actual newline character and <SP> are spaces.
I think I simply kept testing with pre-wrap rather than pre. Not sure.

However, I think pre is a better choice, like you mentioned.

I did some tests again (with spaces, newlines), and in all cases that I tested the pre seemed to produce more desirable results.
For example, the ellipsis (...) character disappears in some cases (like trailing spaces) when using pre-wrap, but with pre it's shown.
And the content doesn't need to wrap, like you mentioned.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/da329064b7ef
show multiple subsequent spaces in file listings, r=valentin

Comment 7

[:Gijs (he/him)]

(In reply to Jelle Geerts from comment #5)

I did some tests again (with spaces, newlines), and in all cases that I tested the pre seemed to produce more desirable results.

Great! I've credited you in the patch description as you pretty much told me how to fix this - thanks again!

This has landed on our integration branch and should be in our nightly builds in the next 24 hours.

Comment 8

[Jelle Geerts]

(In reply to :Gijs (he/him) from comment #7)

Great! I've credited you in the patch description as you pretty much told me how to fix this - thanks again!

How kind, thank you.

Comment 9

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/da329064b7ef