Closed Bug 1403986 Opened 2 years ago Closed 2 years ago

Ellipses on parent hides children with display inline

Categories

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

57 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla59
Tracking Status
firefox57 --- wontfix
firefox59 --- fixed

People

(Reporter: jake+mozilla, Assigned: mats)

References

Details

Attachments

(5 files)

Attached image 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?
Component: Untriaged → DOM: CSS Object Model
Product: Firefox → Core
Status: UNCONFIRMED → NEW
Component: DOM: CSS Object Model → Layout: Block and Inline
Ever confirmed: true
Priority: -- → P3
Attached file 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.)
Filed bug 1426261 for the incremental layout issue mentioned at the end of comment 1.
See Also: → 1426261
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 :/
Attached file 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.
Assignee: nobody → mats
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.
Attachment #8938890 - Flags: review?(jfkthame)
Attachment #8938890 - Flags: review?(jfkthame) → review+
Attachment #8938891 - Flags: review?(jfkthame) → review+
Pushed by mpalmgren@mozilla.com:
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.
Flags: in-testsuite+
https://hg.mozilla.org/mozilla-central/rev/11ad483f7e4f
https://hg.mozilla.org/mozilla-central/rev/47098bf648b4
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
You need to log in before you can comment on or make changes to this bug.