Bug 98597 – Text overflow ellipsis is affected by vertical-align

• Component: Layout and Rendering
• Status: UNCONFIRMED

[Daniel Trebbien]

Created attachment 167454 [details]
Test case

If you look at the attached test case, you will see that the text "This is a test. Testing 1 2 3. Blah blah blah." is vertically centered within the box, but the ellipsis generated by text-overflow is placed much higher, apparently affected by the vertical-align on the <span>.

[Rob Buis]

Created attachment 174858 [details]
Patch

[WebKit Review Bot]

Comment on attachment 174858 [details]
Patch

Attachment 174858 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/14908008

New failing tests:
fast/css/text-overflow-ellipsis-vertical-align.html

[Rob Buis]

Created attachment 175212 [details]
Patch

[Rob Buis]

(In reply to comment #3)
> Created an attachment (id=175212) [details]
> Patch

Here is my stab at this. The strategy is simple, put the ellipsis on same y coordinate as the previous inline box where the truncation is made. This looks visually pleasing, though I noted FF and Opera do not do this, they do the same as we do on trunk. So I think we either have to decide to fix this (my patch shows that it is possible) or decide that this is an invalid/wontfix bug.

[Dave Hyatt]

Comment on attachment 175212 [details]
Patch

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

r-

Get me a vertical-rl test also please.

> Source/WebCore/rendering/InlineBox.h:273
> +    virtual float placeEllipsisBox(bool ltr, float visibleLeftEdge, float visibleRightEdge, float ellipsisWidth, float &truncatedWidth, bool&, float&);

You should include a parameter name here, since it's not clear what the extra float is otherwise.

> Source/WebCore/rendering/InlineFlowBox.h:197
> +    virtual float placeEllipsisBox(bool ltr, float blockLeftEdge, float blockRightEdge, float ellipsisWidth, float &truncatedWidth, bool&, float&) OVERRIDE;

Ditto.

> Source/WebCore/rendering/InlineTextBox.cpp:249
> +        boxY = y();

Shouldn't this be logicalTop()?

> Source/WebCore/rendering/InlineTextBox.cpp:265
> +        boxY = y();

Ditto.

> Source/WebCore/rendering/InlineTextBox.cpp:273
> +        boxY = y();

Ditto.

> Source/WebCore/rendering/RootInlineBox.cpp:153
>      ellipsisBox->setX(position);
> +    if (foundBox)
> +        ellipsisBox->setY(boxY);

Not accounting for vertical writing here.

[alan]

Created attachment 207525 [details]
Patch

[alan]

ellipsis with vertical direction is so broken that I didn't even try to add a testcase.

[kov's GTK+ EWS bot]

Comment on attachment 207525 [details]
Patch

Attachment 207525 [details] did not pass gtk-ews (gtk):
Output: http://webkit-queues.appspot.com/results/1247203

[alan]

(In reply to comment #8)
> (From update of attachment 207525 [details])
> Attachment 207525 [details] did not pass gtk-ews (gtk):
> Output: http://webkit-queues.appspot.com/results/1247203
looks totally unrelated.

[Build Bot]

Comment on attachment 207525 [details]
Patch

Attachment 207525 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/1248299

New failing tests:
editing/selection/leak-document-with-selection-inside.html

[Build Bot]

Created attachment 207545 [details]
Archive of layout-test-results from webkit-ews-07 for mac-mountainlion

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-07  Port: mac-mountainlion  Platform: Mac OS X 10.8.3

[Karl Dubost]

Created attachment 460003 [details]
rendering in Safari, firefox, chrome

Safari, Firefox and Chrome all render the same layout, which is indeed slightly weird from a user point of view.

[Radar WebKit Bug Importer]

<rdar://problem/94334315>

[Karl Dubost]

> The ellipsis is styled and baseline-aligned according to the block.
— https://drafts.csswg.org/css-overflow-4/#ellipsing-details

[Karl Dubost]

Probably https://bugs.chromium.org/p/chromium/issues/detail?id=496850

[alan]

This looks correct to me (while I agree it does look a bit odd). if you put some content outside of the inline box, you can see that the ellipsis (correctly) sits on the baseline as per spec. What's happening here is that the inline box with stretching line-height and vertical-align makes the ellipsis look misplaced, but in practice it just follows the block's baseline.