Bug 25277

Summary:

If there is no line wrapping, a caret can leave its containing block but it shouldn't leave its root line box

Product:

WebKit

Reporter:

Justin Garcia <justin.garcia>

Component:

Layout and Rendering

Assignee:

Justin Garcia <justin.garcia>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

mitz, simon.fraser

Priority:

Keywords:

InRadar

Version:

528+ (Nightly build)

Hardware:

Mac

OS:

OS X 10.5

Attachments:

Description	Flags
patch	none
patch	mitz: review+

Justin Garcia

Reported 2009-04-17 16:15:51 PDT

If there is no line wrapping, a caret can leave its containing block but it shouldn't leave its root line box. Otherwise I believe it can be clipped by the containing blocks outline. Test case forthcoming. <rdar://problem/6800956>

Attachments
patch (5.17 KB, patch) 2009-04-17 16:50 PDT, Justin Garcia	no flags	Details Formatted Diff Diff
patch (7.80 KB, patch) 2009-04-17 17:38 PDT, Justin Garcia	mitz: review+	Details Formatted Diff Diff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.

Justin Garcia

Comment 1 2009-04-17 16:50:54 PDT

Created attachment 29593 [details] patch

mitz

Comment 2 2009-04-17 17:02:58 PDT

Comment on attachment 29593 [details] patch You should add a reference to the test to the WebCore ChangeLog. I don't think this covers all cases. Not all textAlign() values that are not LEFT should behave the same, and I think in most cases (maybe even for LEFT and RIGHT) the behavior also needs to take style()->direction() into account, because that's how we decide on which side of the block the overflow goes. See the logic in RenderBlock::computeHorizontalPositionsForLine().

Justin Garcia

Comment 3 2009-04-17 17:04:22 PDT

(In reply to comment #2) > Not all textAlign() values that are not LEFT should behave the same oops! will fix...

Justin Garcia

Comment 4 2009-04-17 17:38:28 PDT

Created attachment 29597 [details] patch patch with new test case to cover the case that dan mentioned, where the text-align is right but the direction is LTR. In that case we spill over to the right off the block like we do in other direction:LTR cases.

mitz

Comment 5 2009-04-17 18:31:14 PDT

Comment on attachment 29597 [details] patch r=me There's a problem with this and earlier caret painting patches in that the difference between correct and incorrect behavior in the pixel test is below our detection threshold. I am not sure what to do about it (maybe use the Mac SPI that's exposed via DRT for getting caret rects?), but addressing that is not part of this bug.

Simon Fraser (smfr)

Comment 6 2009-04-17 18:33:19 PDT

Maybe caretWidth should be settable at runtime via a CSS property, or DRT API, and we can make it really fat?

mitz

Comment 7 2009-04-17 18:35:48 PDT

I don't think we want a CSS property for it, but maybe a WebView SPI.

Justin Garcia

Comment 8 2009-04-17 18:38:16 PDT

I'll correct the test description to say that the problem is that the caret paints over the focus halo a bit (rather than getting clipped).

Justin Garcia

Comment 9 2009-04-17 18:54:25 PDT

http://trac.webkit.org/changeset/42634

Justin Garcia

Comment 10 2009-04-17 19:00:29 PDT

and http://trac.webkit.org/changeset/42635

Note You need to log in before you can comment on or make changes to this bug.