1843420 - file:/// URLs are not truncated in tabs list view

Status: NEW

(Firefox :: Firefox View, defect, P3)

Description

[Amy Lee [:amylee] UX]

Attachment: Screen Shot 2023-07-13 at 3.50.40 PM.png

Steps to reproduce:

1. Open a google doc with a long URL
2. Go to print
3. Go to Firefox view to "Recent browsing" –> "Open tabs"

Expected:
URL is truncated with ellipsis (…)

Actual:
Shows entire URL that breaks into multiple lines

Please see attached screenshot for reference.

Comment 1

[Sam Foster [:sfoster] (he/him)]

This reproduces with both Open Tabs and Recently Closed Tabs, and seems to happen with any file:/// URL, where there is no host/hostname to use for the item label. While we use nowrap and text-overflow: ellipsis to truncate the title column, for the URL we use word-break: break-word; and let it wrap rather than truncate - to avoid confusion with similar hostnames.

The potential filename lengths we need to display aren't completely unbounded - there are practical filename length limits but they vary from platform to platform. For windows it is 260 characters, elsewhere 1024.

For an implementation approach, we can tag rows with no hostname to get different display rules via a CSS class. I'm not sure what those should be though - maybe we can allow wrap over max 3 lines and ellipsize after that?

FWIW, elsewhere, we use a xul:description element with crop=center which handily ellipsizes the filename at the middle, rather than truncating at the end where important distinguishing information is likely to be (like version numbers, file extension etc). That is a XUL-only feature however and there's no equivalent HTML/CSS solution that I'm aware of. We could of course use a xul:description element there - I don't know how we feel about that.

Regardless, I do think we should avoid preparing a pre-truncated string in javascript however. You would need to calculate the size of the column and how many characters at the current font/font-size would fit, and then be prepare to re-run the whole calculation on resize.. This is layout work, and we'll never get it quite right from the front-end.

The other viable alternative is to close this bug as WONTFIX if no great solution presents itself, or if we determine that the risk of losing valuable information in this context outweighs the harm represented by the wrapping filenames and tall item rows.