RESOLVED FIXED 5619
CSS2: pre-wrap has overflow/selection problems 
https://bugs.webkit.org/show_bug.cgi?id=5619
Summary CSS2: pre-wrap has overflow/selection problems
Dave Hyatt
Reported 2005-11-03 13:06:31 PST
See the test case attached to bug 5593. The first line when editing cleanly keeps the caret in the block, but the selection is allowed to extend outside the block. Also, if you put overflow onto the pre, there seems to be a slight rounding error. A horizontal scrollbar exists that lets you scroll the block slightly. No scrollbar should appear.
Attachments
Patch to fix scrollbar problem (821 bytes, patch)
2005-11-26 22:16 PST, David Smith 		no flags
DetailsFormatted DiffDiff
Example file for the scrollbar problem (251 bytes, text/html)
2005-11-26 22:21 PST, David Smith 		no flags
Details
Proposed patch (9.34 KB, patch)
2006-01-08 13:32 PST, mitz 		no flags
DetailsFormatted DiffDiff
Revised patch (8.66 KB, patch)
2006-01-15 08:46 PST, mitz 		darin: review+
DetailsFormatted DiffDiff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.
David Smith
Comment 1 2005-11-23 01:57:04 PST
The second issue mentioned (the un-needed scrollbar) also occurs on other types of elements when the width is exactly right, and overflow:auto is set. We run into this relatively often in narrow Adium windows due to our use of webkit in the message view.
David Smith
Comment 2 2005-11-26 22:16:26 PST
Created attachment 4812 [details] Patch to fix scrollbar problem This appears to fixes the horizontal scrollbar issue, and passed the regression tests when I ran them. It appears that the width calculations were ignoring one border, but not the other, and only get the correct results when they ignore both.
David Smith
Comment 3 2005-11-26 22:21:29 PST
Created attachment 4813 [details] Example file for the scrollbar problem
David Smith
Comment 4 2005-11-26 22:50:25 PST
Comment on attachment 4812 [details] Patch to fix scrollbar problem mitzpettel on irc points out a test case in which this patch fails. It looks like it's specifically related to text wrapping in some way, not borders as I suspected at first.
Eric Seidel (no email)
Comment 5 2005-12-28 00:36:42 PST
The test case is not entirely clear to me (what I'm supposed to be seeing) but it looks "wrong" still on TOT.
mitz
Comment 6 2006-01-08 13:32:39 PST
Created attachment 5552 [details] Proposed patch
Darin Adler
Comment 7 2006-01-09 09:03:13 PST
Comment on attachment 5552 [details] Proposed patch Looks good to me. What happens if tx + m_x + m_width - r.left() is negative in InlineTextBox::selectionRect? Extra space after "r.setWidth" in InlineTextBox::selectionRect.
mitz
Comment 8 2006-01-15 08:46:46 PST
Created attachment 5698 [details] Revised patch
Darin Adler
Comment 9 2006-01-15 13:40:41 PST
Comment on attachment 5698 [details] Revised patch Looks fine. I'd like a comment for the change log about the computeHorizontalPositionsForLine change.
Darin Adler
Comment 10 2006-01-15 13:43:34 PST
The comment should be something like: "Remove code that re-added border width which was already included in availableWidth."
Note You need to log in before you can comment on or make changes to this bug.