Closed Bug 1638086 Opened 2 months ago Closed 1 month ago

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

Categories

(Core :: Networking, defect)

75 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla78
Tracking Status
firefox-esr68 --- wontfix
firefox76 --- wontfix
firefox77 --- wontfix
firefox78 --- fixed

People

(Reporter: jellegeerts, Assigned: Gijs)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

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.

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.

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

Keywords: regression
Regressed by: 294800
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: Untriaged → File Handling
Component: File Handling → Networking
Product: Firefox → Core
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED

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...

Assignee: gijskruitbosch+bugs → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(jellegeerts)
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED

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.

Flags: needinfo?(jellegeerts)
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/da329064b7ef
show multiple subsequent spaces in file listings, r=valentin

(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.

(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.

Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78
You need to log in before you can comment on or make changes to this bug.