1403986 - Ellipses on parent hides children with display inline

Status: RESOLVED FIXED

(Core :: Layout: Block and Inline, defect, P3)

Description

[Jake Howard]

Attachment: Example in firefox 55

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170918122929
Firefox for Android

Steps to reproduce:

https://jsfiddle.net/hnq3v3e5/2/

See JSFiddle for accurate reproduction. Can be reproduced in 57 developer edition, and 55 standard, on both Linux and MacOS.




Actual results:

Firefox will not display an ellipses (example...) correctly if the children of the node with the ellipsis styles are inline-block. Instead it just displays the ellipsis (...).


Expected results:

it should probably do what all the other browsers appear to do (Safari & IE at least), and just cut the text. In a far more reliable way.

It's possible this is because firefox adheres more to the web standards than other browsers?

Comment 1

[Xidorn Quan [:xidorn] UTC+10]

Attachment: a testcase

This is a testcase showing different handling of atomic inline elements in different engines.

Firefox treats atomic inline elements as a single grapheme, and thus it uses ellipsis when it is being clipped.

Chrome doesn't apply ellipsis on atomic inline element itself, and thus in the second line of the testcase, where there are multiple <img>s, there is no ellipsis. However, it somehow makes the inline-block "inherit" the text-overflow and applies ellipsis inside the inline-block.

Edge has a smarter strategy to avoid this issue: it replaces atomic inline element with ellipsis only when the line is not otherwise empty, that is, the line should never show only ellipsis.

I guess we can use Edge's strategy, which is probably not too complicated, and it makes sense.

Chrome's behavior is undesired for the second line case. For the inline-block case, it may be better than others (although I'm not sure), but it could be a bit more complicated.

(Note that there seems to be a bug that the first line and last line wouldn't have ellipsis applied directly. To observe the above result in Firefox, you would need to open Inspector. This is a separate bug.)

Comment 2

[Xidorn Quan [:xidorn] UTC+10]

Filed bug 1426261 for the incremental layout issue mentioned at the end of comment 1.

Comment 3

[Xidorn Quan [:xidorn] UTC+10]

This may be worth raising a spec issue to CSS UI 3, but given the incremental layout issue, I'm hesitant to file so, because the reproduce steps would be more tricky :/

Comment 4

[Mats Palmgren (inactive)]

Attachment: A few more tests

The reason the original testcase (https://jsfiddle.net/hnq3v3e5/2/)
ellipsizes away the inline-block is that there is a white-space
before it on the line (the white-space between the two <span>s).

That's a non-significant white-space though and it's trimmed away
in layout, so it shouldn't count as "the first character" in the spec sense.
https://drafts.csswg.org/css-ui-4/#text-overflow
"The first character or atomic inline-level element on a line must
be clipped rather than ellipsed."

But since we do, we ellipsize away the inline-block that follows
since we believe it's the second thing on the line.
This is a bug in Firefox.

> It's possible this is because firefox adheres more to the web standards than
> other browsers?

Yes, we follow the spec pretty closely.  Chrome has major bugs in their
implementation of text-overflow, especially for "atomic inline-level element"s.

('inline-block' boxes counts as "atomic inline-level element"
in the css-ui spec and should be ellipsized as an atomic unit.)

The second block in this test fails in Firefox.
Chrome renders all five blocks wrong.

Comment 5

[Mats Palmgren (inactive)]

Attachment: part 1 - [css-ui] Treat text frames with only trimmable space as empty for 'text-overflow' purposes

We already have an aFoundVisibleTextOrAtomic param for this purpose.
Currently we unconditionally set it to true when we find a text
frame.  This patch adds the requirement that it must have some
non-trimmable text.

Comment 6

[Mats Palmgren (inactive)]

Attachment: part 2 - [css-ui] Add a 'text-overflow' web platform test

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/11ad483f7e4f
part 1 - [css-ui] Treat text frames with only trimmable space as empty for 'text-overflow' purposes.  r=jfkthame
https://hg.mozilla.org/integration/mozilla-inbound/rev/47098bf648b4
part 2 - [css-ui] Add a 'text-overflow' web platform test.

Comment 8

[Tiberius Oros[:tiberius_oros]]

https://hg.mozilla.org/mozilla-central/rev/11ad483f7e4f
https://hg.mozilla.org/mozilla-central/rev/47098bf648b4