Closed Bug 1716572 Opened 4 months ago Closed 2 months ago

ellipsis in table td appears but clientWidth is equal to scrollWidth

Categories

(Core :: Layout: Tables, defect, P3)

78 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1226695

People

(Reporter: arne_bab, Unassigned)

Details

Attachments

(3 files)

Attached file broken-ellipsis.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 IceCat/78.0

Steps to reproduce:

Create a table as in the attached example, fiddle with the td-width to match the content width exactly.

Actual results:

The sixth text element is shortened with an ellipsis, but td clientWidth and scrollWidth are both 54. Due to this, there is no way to detect performantly that an ellipsis was used to shorten the text.

Expected results:

When the content is shortened with an ellipsis, scrollWidth should always be larger than clientWidth.

Attached image broken-ellipsis.png

The attached file also includes a workaround: wrapping the content of the td into a div. This however doubles the number of DOM-elements, so it is still impossible to detect the ellipsis with good performance.

There is a related issue for Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=980476

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Tables' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Layout: Tables
Product: Firefox → Core

clientWidth/scrollWidth returns integers so when the underlying internal layout size has a fractional value, say 54.1px, then it will be rounded before returning. https://drafts.csswg.org/cssom-view/#extension-to-the-element-interface

Status: UNCONFIRMED → RESOLVED
Closed: 4 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1226695

This is not just a rounding problem: as you can see in the example, the differences jump from 54/54 to 54/59. The second case with the content wrapped in a div shows that the scroll width of the content actually increased from 52 to 53.

Why is the td scrollWidth and clientWidth 54, if an included div of the content only has scrollWidth 53? Why is the td content ellipsized when there would still be 1 pixel unoccupied space compared to the div — or who does the scrollWidth not increase beyond 54.

In production I’ve seen this ellipsize up to 3 letters in the td while the clientWidth and scrollWidth are still equal, so the difference is much bigger than the one pixel that could be caused by rounding.

Reopened, because this is not a duplicate. There is not just a fraction of a pixel mismatch, but 4 pixels, and the bug does not appear in Chrome.

Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---

The scrollWidth and clientWidth of the <td> includes the cell's padding, which by default is 1px; if you set td { padding: 0 } it may be easier to figure out what is going on.

It may ellipsize several letters while the clientWidth and scrollWidth are "equal" (subject to rounding), because once the precise layout width is fractionally over a pixel (e.g. I get 52.3833px for the text "Testeri", which is reported as 52px by scrollWidth but will not actually fit within a 52px cell), the ellipsis itself occupies space and may result in several more letters being ellipsized.

It's still not really clear to me if there is an issue here other than the fact that the ellipsis may appear when the text "overflows" by only a fraction of a pixel (perhaps that's not desirable).

We should land https://phabricator.services.mozilla.com/D95485, but it caused some test issues with weird DPIs on android.

Attached file reduced example

FWIW, here's a reduced example that exhibits the same "issue" (the text in the table cell being ellipsized, even though scrollWidth and clientWidth report the same value, appearing to imply it should fit without overflow) in both Firefox and Chromium, at least on my Linux machine. (Depends on Bitstream Vera Sans being installed.)

Both Firefox and Chromium show me

Test… td clientWidth 52 scrollWidth 52

for the third row here, because the text "Testeri" is actually a fraction over 52px wide.

Severity: -- → S3
Priority: -- → P3

(In reply to Jonathan Kew (:jfkthame) from comment #7)

It may ellipsize several letters while the clientWidth and scrollWidth are "equal" (subject to rounding), because once the precise layout width is fractionally over a pixel (e.g. I get 52.3833px for the text "Testeri", which is reported as 52px by scrollWidth but will not actually fit within a 52px cell), the ellipsis itself occupies space and may result in several more letters being ellipsized.

Right, that's the expected behavior. I feel rather strongly that we shouldn't mess with ellipsing just to accommodate this edge case that is caused by "wrong" (rounded) values being reported by clientWidth/scrollWidth. See bug 1226695 comment 9 for a way to work around it (use getBoundingClientRect() instead).

Status: UNCONFIRMED → RESOLVED
Closed: 4 months ago2 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1226695
You need to log in before you can comment on or make changes to this bug.