Bug 5461

Summary: Text width measured incorrectly when text-align: justify
Product: WebKit Reporter: Duncan Wilcox <duncan>
Component: Layout and RenderingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Minor CC: ap, dbates, mitz
Priority: P2 Keywords: HasReduction
Version: 420+   
Hardware: Mac   
OS: OS X 10.4   
Attachments:
Description Flags
test case
none
Automated test case
none
Work in progress
none
Use WebTextRenderer selection rects darin: review+

Duncan Wilcox
Reported 2005-10-22 10:18:08 PDT
Load attached sample document, hold cmd-ctrl and hit "d" (keep holding cmd-ctrl), now hovering over words pops up the dictionary lookup. Hover towards ends of lines, the highlited text isn't exactly aligned with the word beneath it. The only strange thing in the sample document is the "text-align: justify". More specifically the highlighted text appears to be aligned on the non justified word position. Tested with freshly checked out tree, this is printed to the console: ================= ERROR: TEXTINPUT: characterIndexForPoint: not yet implemented (/Users/duncan/builds/WebKit/WebView.subproj/WebHTMLView.m:4874 -[WebHTMLView (WebNSTextInputSupport) characterIndexForPoint:]) =================
Attachments
test case (1.34 KB, text/html)
2005-10-22 10:18 PDT, Duncan Wilcox
no flags
Automated test case (935 bytes, text/html)
2005-10-22 13:35 PDT, Alexey Proskuryakov
no flags
Work in progress (13.08 KB, patch)
2005-12-29 07:14 PST, mitz
no flags
Use WebTextRenderer selection rects (23.95 KB, patch)
2005-12-30 02:25 PST, mitz
darin: review+
Duncan Wilcox
Comment 1 2005-10-22 10:18:46 PDT
Created attachment 4442 [details] test case
Alexey Proskuryakov
Comment 2 2005-10-22 13:34:49 PDT
Justified text also has serious problems when being edited in Blot and Mail; I think the root cause is the same. To reproduce, open the test case in Blot and try moving the caret with arrow keys or mouse clicks - its positioning doesn't account for the justification. Renaming the bug and bumping priority to P2. BTW, an implementation for characterIndexForPoint is currently in the commit queue (bug 5230), and it doesn't help in this case.
Alexey Proskuryakov
Comment 3 2005-10-22 13:35:52 PDT
Created attachment 4443 [details] Automated test case
Eric Seidel (no email)
Comment 4 2005-12-27 15:36:32 PST
Particularly "note" and "are" in the second paragraph.
mitz
Comment 5 2005-12-29 07:14:42 PST
Created attachment 5353 [details] Work in progress
mitz
Comment 6 2005-12-30 02:25:04 PST
Created attachment 5376 [details] Use WebTextRenderer selection rects There's more to this patch than just fixing the bug: past fixes to "highlight leaves trails" were about narrowing WebTextRenderer's highlight rect to fit into InlineTextBox's selectionRect, which due to the "rounding hack" was narrower than AppKit's highlight rect for the same text. By moving all selection/highlight rect computations to WebTextRenderer, this patch eliminates unnecessary intermediate rounding and gives wider rects that match AppKit more closely. I think it also improves caret positioning in RTL text. It looks like AppKit uses different rounding modes for the right hand side of the highlight (ceil) and for the caret (round). This patch sacrifices highlight to get caret right. I guess this can be improved in the future.
Darin Adler
Comment 7 2005-12-30 11:29:42 PST
Comment on attachment 5376 [details] Use WebTextRenderer selection rects Nice. r=me
Daniel Bates
Comment 8 2017-12-05 13:12:07 PST
Note You need to log in before you can comment on or make changes to this bug.