Bug 115746 – The ellipsis in a text overflow should not avoid floats

• Status: RESOLVED
• Resolution: INVALID
• Component: New Bugs

[WebKit Commit Bot]

Inline box with white-space:nowrap being cliiped at right edge of floated right input
Requested by rhogan on #webkit.

[Robert Hogan]

Created attachment 200948 [details]
Reduction

[Robert Hogan]

This shadows https://code.google.com/p/chromium/issues/detail?id=237078

[Robert Hogan]

I think the bug might actually be that we perform the ellipsis before the floating input element. We should do the same as firefox and render the ellipsis at the div's boundary.

[Robert Hogan]

Created attachment 202235 [details]
Patch

[Robert Hogan]

*** Bug 113229 has been marked as a duplicate of this bug. ***

[alan]

We concluded at <rdar://problem/13008605> that clipping the text at the floating element instead of the containing box is the expected behaviour and hence bug 115675

[Robert Hogan]

(In reply to comment #6)
> We concluded at <rdar://problem/13008605> that clipping the text at the floating element instead of the containing box is the expected behaviour and hence bug 115675

That conclusion seems inconsistent with the rendering of overflow:hidden when no text-overflow rendering is specified.

[alan]

(In reply to comment #7)
> (In reply to comment #6)
> > We concluded at <rdar://problem/13008605> that clipping the text at the floating element instead of the containing box is the expected behaviour and hence bug 115675
> 
> That conclusion seems inconsistent with the rendering of overflow:hidden when no text-overflow rendering is specified.
Correct and according to this (http://lists.w3.org/Archives/Public/www-style/2013Apr/0566.html) and this (https://bugzilla.mozilla.org/show_bug.cgi?id=864759), FF's rendering is claimed to be per spec as opposed to Safari's. (and IE)
However, since Safari's current rendering looks visually more correct, and also to not to cause regression, we thought fixing hittest was the right thing to do.

ccing Simon.

[Dave Hyatt]

Comment on attachment 202235 [details]
Patch

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

> Source/WebCore/rendering/RenderBlockLineLayout.cpp:3473
> +        int blockLeftEdge = ltr ? pixelSnappedLogicalLeftOffsetForLine(curr->lineTop(), firstLine) : logicalLeftOffsetForContent(curr->lineTop());

Don't you need to pixel snap?

[Robert Hogan]

Created attachment 202320 [details]
Patch

[Dave Hyatt]

Comment on attachment 202320 [details]
Patch

r=me

[Robert Hogan]

Committed r150602: <http://trac.webkit.org/changeset/150602>

[Benjamin Poulain]

Looks like you submitted your test with Windows line ending.

[Timothy Hatcher]

This broke a few places in the Safari Web Inspector where we rely on float avoiding the ellipsis. The new behavior is incomprehensible to me and the old behavior makes sense. There is now no way to get the old behavior, unless someone wants to enlighten me.

I suggest we revert this or add some way to get the old behavior.

[Timothy Hatcher]

Created attachment 203520 [details]
Broken Inspector 1

[Timothy Hatcher]

Created attachment 203521 [details]
Broken Inspector 2

[Timothy Hatcher]

As far as I am conceded, overflow: hidden and text-overflow are completely different beasts. With text-overflow: ellipsis you are requesting better handling of text when it overflows or runs out of room on the line. You might as well not even bother now if this is the new "behavior" with floats.

[Timothy Hatcher]

Sigh. s/conceded/concerned/

[alan]

I am rolling this out as the result of the discussion with smfr, hyatt and xenon (1, breaking the inspector  2, the overall functionality of floating element vs. text-overflow.)

[alan]

https://bugs.webkit.org/show_bug.cgi?id=117871

[alan]

Committed r151836: <http://trac.webkit.org/changeset/151836>

[Boris Zbarsky]

If you think the spec is wrong, shouldn't you at least send spec feedback to that effect?