Summary: | The ellipsis in a text overflow should not avoid floats | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | WebKit Commit Bot <commit-queue> | ||||||||||||
Component: | New Bugs | Assignee: | Robert Hogan <robert> | ||||||||||||
Status: | RESOLVED INVALID | ||||||||||||||
Severity: | Normal | CC: | benjamin, bzbarsky, dtrebbien, esprehn+autocc, glenn, jamesr, MatsPalmgren_bugz, robert, simon.fraser, timothy, zalan | ||||||||||||
Priority: | P2 | ||||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||||
Hardware: | Unspecified | ||||||||||||||
OS: | Unspecified | ||||||||||||||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=115462 | ||||||||||||||
Attachments: |
|
Description
WebKit Commit Bot
2013-05-07 11:33:00 PDT
Created attachment 200948 [details]
Reduction
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. Created attachment 202235 [details]
Patch
*** Bug 113229 has been marked as a duplicate of this bug. *** 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 (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. (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. 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? Created attachment 202320 [details]
Patch
Comment on attachment 202320 [details]
Patch
r=me
Committed r150602: <http://trac.webkit.org/changeset/150602> Looks like you submitted your test with Windows line ending. 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. Created attachment 203520 [details]
Broken Inspector 1
Created attachment 203521 [details]
Broken Inspector 2
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. Sigh. s/conceded/concerned/ 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.) Committed r151836: <http://trac.webkit.org/changeset/151836> If you think the spec is wrong, shouldn't you at least send spec feedback to that effect? |