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.

[zalan]

Created attachment 207525 [details]
Patch

[zalan]

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

[zalan]

(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