Bug 101879 – text-overflow:ellipsis is not applied when the block contains nested blocks

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[Philippe Wittenbergh]

WebKit falls back to text-overflow: clip (the default). Firefox and Opera handle this correctly.

Example: 4th example in the spec;
http://www.w3.org/TR/css3-ui/#text-overflow
http://dev.w3.org/csswg/css3-ui/#text-overflow

Sample markup
<div style="text-overflow:ellipsis; overflow:hidden"> NESTED <p>PARAGRAPH</p> WON'T ELLIPSE. </div>

[Philippe Wittenbergh]

Created attachment 173534 [details]
test case from the spec

Expected results: an ellipsis after the words:'nested', 'won't and 'ellipse'.
Actual results: no ellipsis is shown.

[Bem Jones-Bey]

Created attachment 188244 [details]
Patch

Fix for bug

[Eric Seidel (no email)]

Comment on attachment 188244 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=188244&action=review

> Source/WebCore/rendering/RenderBlockLineLayout.cpp:1828
>      // FIXME: CSS3 says that descendants that are clipped must also know how to truncate.  This is insanely
>      // difficult to figure out (especially in the middle of doing layout), and is really an esoteric pile of nonsense
>      // anyway, so we won't worry about following the draft here.

It looks like you're partially implementing this FIXME.  Do we care about the multiple-nested anonymous block case?

> Source/WebCore/rendering/RenderBlockLineLayout.cpp:1830
> +    bool hasTextOverflow = (style()->textOverflow() && hasOverflowClip())
> +        || (isAnonymousBlock() && parent() && parent()->isRenderBlock() && parent()->style()->textOverflow() && parent()->hasOverflowClip());

Since textOverflow is the uncommon case, this will always hit the second part of the branch, but will exit quickly with the isAnonymousBlock check.  I dno't think this code is super-hot, but it's on a common path.

[Bem Jones-Bey]

(In reply to comment #3)
> (From update of attachment 188244 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=188244&action=review
> 
> > Source/WebCore/rendering/RenderBlockLineLayout.cpp:1828
> >      // FIXME: CSS3 says that descendants that are clipped must also know how to truncate.  This is insanely
> >      // difficult to figure out (especially in the middle of doing layout), and is really an esoteric pile of nonsense
> >      // anyway, so we won't worry about following the draft here.
> 
> It looks like you're partially implementing this FIXME.  Do we care about the multiple-nested anonymous block case?

Can you explain to me when this case happens (or link to the spec that describes this behavior)?

It is possible that it makes the most sense to just update the FIXME saying that it doesn't work in the multiple nested anonymous block case and file a bug for that.

> > Source/WebCore/rendering/RenderBlockLineLayout.cpp:1830
> > +    bool hasTextOverflow = (style()->textOverflow() && hasOverflowClip())
> > +        || (isAnonymousBlock() && parent() && parent()->isRenderBlock() && parent()->style()->textOverflow() && parent()->hasOverflowClip());
> 
> Since textOverflow is the uncommon case, this will always hit the second part of the branch, but will exit quickly with the isAnonymousBlock check.  I dno't think this code is super-hot, but it's on a common path.

I'm not sure I understand what needs to be changed here. Are you suggesting that I flip around the order of the conditions in the or expression?

[Bem Jones-Bey]

Created attachment 189547 [details]
Patch

Updated FIXME comment to reflect that this change fixes part of what it is referring to.

[Eric Seidel (no email)]

Comment on attachment 189547 [details]
Patch

This seems reasonable to me.  Mitz and Hyatt are CC'd and can scream if they disagree.

[WebKit Review Bot]

Comment on attachment 189547 [details]
Patch

Clearing flags on attachment: 189547

Committed r143754: <http://trac.webkit.org/changeset/143754>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.