Bug 115746 - The ellipsis in a text overflow should not avoid floats
Summary: The ellipsis in a text overflow should not avoid floats
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Robert Hogan
URL:
Keywords:
: 113229 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-05-07 11:33 PDT by WebKit Commit Bot
Modified: 2013-11-29 15:27 PST (History)
11 users (show)

See Also:


Attachments
Reduction (894 bytes, text/html)
2013-05-07 11:33 PDT, Robert Hogan
no flags Details
Patch (8.08 KB, patch)
2013-05-19 08:34 PDT, Robert Hogan
no flags Details | Formatted Diff | Diff
Patch (8.12 KB, patch)
2013-05-20 14:34 PDT, Robert Hogan
hyatt: review+
Details | Formatted Diff | Diff
Broken Inspector 1 (16.25 KB, image/png)
2013-06-02 08:09 PDT, Timothy Hatcher
no flags Details
Broken Inspector 2 (10.21 KB, image/png)
2013-06-02 08:10 PDT, Timothy Hatcher
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description WebKit Commit Bot 2013-05-07 11:33:00 PDT
Inline box with white-space:nowrap being cliiped at right edge of floated right input
Requested by rhogan on #webkit.
Comment 1 Robert Hogan 2013-05-07 11:33:33 PDT
Created attachment 200948 [details]
Reduction
Comment 2 Robert Hogan 2013-05-07 11:33:57 PDT
This shadows https://code.google.com/p/chromium/issues/detail?id=237078
Comment 3 Robert Hogan 2013-05-18 04:39:10 PDT
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.
Comment 4 Robert Hogan 2013-05-19 08:34:00 PDT
Created attachment 202235 [details]
Patch
Comment 5 Robert Hogan 2013-05-19 10:18:56 PDT
*** Bug 113229 has been marked as a duplicate of this bug. ***
Comment 6 zalan 2013-05-19 10:23:07 PDT
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
Comment 7 Robert Hogan 2013-05-19 10:58:56 PDT
(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.
Comment 8 zalan 2013-05-19 11:21:50 PDT
(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 9 Dave Hyatt 2013-05-20 12:52:01 PDT
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?
Comment 10 Robert Hogan 2013-05-20 14:34:32 PDT
Created attachment 202320 [details]
Patch
Comment 11 Dave Hyatt 2013-05-22 13:51:09 PDT
Comment on attachment 202320 [details]
Patch

r=me
Comment 12 Robert Hogan 2013-05-23 11:56:18 PDT
Committed r150602: <http://trac.webkit.org/changeset/150602>
Comment 13 Benjamin Poulain 2013-05-27 22:13:46 PDT
Looks like you submitted your test with Windows line ending.
Comment 14 Timothy Hatcher 2013-06-02 08:03:36 PDT
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.
Comment 15 Timothy Hatcher 2013-06-02 08:09:49 PDT
Created attachment 203520 [details]
Broken Inspector 1
Comment 16 Timothy Hatcher 2013-06-02 08:10:06 PDT
Created attachment 203521 [details]
Broken Inspector 2
Comment 17 Timothy Hatcher 2013-06-02 08:15:23 PDT
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.
Comment 18 Timothy Hatcher 2013-06-02 08:16:02 PDT
Sigh. s/conceded/concerned/
Comment 19 zalan 2013-06-21 03:27:34 PDT
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.)
Comment 21 zalan 2013-06-21 08:47:19 PDT
Committed r151836: <http://trac.webkit.org/changeset/151836>
Comment 22 Boris Zbarsky 2013-11-29 14:20:45 PST
If you think the spec is wrong, shouldn't you at least send spec feedback to that effect?