RESOLVED FIXED Bug 205486
ComplexTextController::offsetForPosition returns a wrong offset for a glyph boundary in a RTL text
https://bugs.webkit.org/show_bug.cgi?id=205486
Summary ComplexTextController::offsetForPosition returns a wrong offset for a glyph b...
Fujii Hironori
Reported 2019-12-19 20:37:14 PST
[Win] imported/blink/editing/selection/offset-from-point-complex-scripts.html is failing since Bug 204884 ComplexTextController::offsetForPosition returns a incorrect offset for RTL text.
Attachments
offset-from-point-complex-scripts-actual.txt of GTK port (20 bytes, text/plain)
2019-12-22 23:38 PST, Fujii Hironori
no flags
Add a new test case with Ahem (1.67 KB, patch)
2019-12-23 00:03 PST, Fujii Hironori
no flags
rtl.html (1.08 KB, text/html)
2019-12-23 01:14 PST, Fujii Hironori
no flags
screenshot of Chrome for Mac with Ahem font (77.30 KB, image/png)
2019-12-23 01:18 PST, Fujii Hironori
no flags
Patch (60.17 KB, patch)
2019-12-23 03:15 PST, Fujii Hironori
no flags
Patch (5.63 KB, patch)
2019-12-23 03:17 PST, Fujii Hironori
no flags
Patch (5.44 KB, patch)
2019-12-23 03:54 PST, Fujii Hironori
no flags
Patch (5.43 KB, patch)
2019-12-23 03:58 PST, Fujii Hironori
no flags
Patch (7.88 KB, patch)
2019-12-23 20:46 PST, Fujii Hironori
no flags
Patch (7.08 KB, patch)
2019-12-23 20:49 PST, Fujii Hironori
no flags
Patch (7.30 KB, patch)
2019-12-24 03:25 PST, Fujii Hironori
no flags
Patch for landing (7.66 KB, patch)
2020-01-06 21:58 PST, Fujii Hironori
no flags
Fujii Hironori
Comment 1 2019-12-22 23:38:38 PST
Created attachment 386327 [details] offset-from-point-complex-scripts-actual.txt of GTK port GTK port is also failing since adopting ComplexTextController.
Fujii Hironori
Comment 2 2019-12-23 00:03:24 PST
Created attachment 386328 [details] Add a new test case with Ahem
Fujii Hironori
Comment 3 2019-12-23 01:10:31 PST
This issue can be reproduced for Mac port. Expected: 6 5 4 3 2 1 0 Actual: 6 5 6 5 4 5 4 3 4 3 2 3 2 1 2 1 0 Chrome for Mac looks working fine. This issue can be reproduced by two conditions: * Glyphs have integral width * using ComplexTextController
Fujii Hironori
Comment 4 2019-12-23 01:12:49 PST
(In reply to Fujii Hironori from comment #3) > This issue can be reproduced by two conditions: > > * Glyphs have integral width > * using ComplexTextController And, * RTL
Fujii Hironori
Comment 5 2019-12-23 01:14:26 PST
Created attachment 386331 [details] rtl.html
Fujii Hironori
Comment 6 2019-12-23 01:18:25 PST
Created attachment 386332 [details] screenshot of Chrome for Mac with Ahem font
Fujii Hironori
Comment 7 2019-12-23 01:54:49 PST
ComplexTextController::offsetForPosition has the following code: > unsigned hitIndex = hitGlyphStart + (hitGlyphEnd - hitGlyphStart) * (m_run.ltr() ? x / adjustedAdvance : 1 - x / adjustedAdvance); If m_run.ltr() is true and x == 0, hitIndex would become hitGlyphEnd. This is not expected.
Fujii Hironori
Comment 8 2019-12-23 03:15:32 PST
Fujii Hironori
Comment 9 2019-12-23 03:17:56 PST
Fujii Hironori
Comment 10 2019-12-23 03:54:06 PST
Fujii Hironori
Comment 11 2019-12-23 03:58:32 PST
Fujii Hironori
Comment 12 2019-12-23 19:44:59 PST
fast/text/ellipsis-text-rtl.html failed on Mac EWS. This is a edge case. In RTL text, the char offset of *previous* glyph needs to be returned for glyph boundary. For example, characters: [A] [B] LTR glyphs: (A) (B) RTL glyphs: (B) (A) Assuming glyph widths are 20px, and argument 'h' of offsetForPosition is 20px, which is the position between (A) and (B). In LTR, glyph (B) is hit, and offset of [B] should be returned. In RTL, glyph (B) is hit, and offset of [B] should be returned. In my patch, in RTL, glyph (A) is hit, and offset of [A] is returned.
Fujii Hironori
Comment 13 2019-12-23 20:46:16 PST
Fujii Hironori
Comment 14 2019-12-23 20:49:35 PST
Fujii Hironori
Comment 15 2019-12-24 03:25:49 PST
Darin Adler
Comment 16 2019-12-26 17:53:50 PST
Comment on attachment 386385 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=386385&action=review > Source/WebCore/platform/graphics/ComplexTextController.cpp:227 > + hitIndex = hitGlyphEnd - (hitGlyphEnd - hitGlyphStart) * (x / adjustedAdvance); Is the rounding here correct? This truncates toward towards the end. Is that what’s intended?
Fujii Hironori
Comment 17 2019-12-27 00:28:36 PST
Comment on attachment 386385 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=386385&action=review Thank you for reviewing my patch. >> Source/WebCore/platform/graphics/ComplexTextController.cpp:227 >> + hitIndex = hitGlyphEnd - (hitGlyphEnd - hitGlyphStart) * (x / adjustedAdvance); > > Is the rounding here correct? This truncates toward towards the end. Is that what’s intended? In my understanding, Neither rounding nor truncating toward the end happen in this expression. Only truncating toward the start can happen by assigning a float value to hitIndex. It is expected.
Fujii Hironori
Comment 18 2020-01-06 03:43:26 PST
Myles, do you have a chance to review this patch? Should I look for other reviewers?
Ross Kirsling
Comment 19 2020-01-06 21:04:31 PST
Comment on attachment 386385 [details] Patch While this isn't my usual reviewing domain, the change and your explanation are quite clear, a test is fixed and another added, and EWS is happy, so that makes me feel pretty good about this patch.
Fujii Hironori
Comment 20 2020-01-06 21:58:19 PST
Created attachment 386935 [details] Patch for landing
Fujii Hironori
Comment 21 2020-01-06 23:50:58 PST
Comment on attachment 386935 [details] Patch for landing Clearing flags on attachment: 386935 Committed r254114: <https://trac.webkit.org/changeset/254114>
Fujii Hironori
Comment 22 2020-01-06 23:51:03 PST
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 23 2020-01-06 23:52:14 PST
Fujii Hironori
Comment 24 2020-01-07 18:05:20 PST
Filed: Bug 205898 – [GTK] fast/text/atsui-rtl-override-selection.html is failing since r254114
Note You need to log in before you can comment on or make changes to this bug.