WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
23786
[Chromium] line-break characters in a complex text are treated as zero-width spaces
https://bugs.webkit.org/show_bug.cgi?id=23786
Summary
[Chromium] line-break characters in a complex text are treated as zero-width ...
Hironori Bono
Reported
2009-02-06 00:53:17 PST
Copied from issue 6135 in Chromium (
http://crbug.com/6135
). Add OK or FAIL after other browsers where you have tested this issue: Safari 3: OK Firefox 3: OK IE 7: OK Chromium: FAIL What steps will reproduce the problem? 1. Make Chromium render a complex text (e.g. a Hebrew text containing nikkuds) whose "white-space" property is "nowrap" or "normal" What is the expected result? Chromium should treat a line-break characters (U+000A and U+000D) in the text as whitespace. What happens instead? Chromium treats line-break characters in the text as zero-width spaces. Please provide any additional information below. Attach a screenshot if possible. This issue is caused by its UniscribeHelper::adjustSpaceAdvances() function that mis-treats the line-break characters as zero-width spaces.
Attachments
Proposed fix for 23786
(118.78 KB, patch)
2009-02-06 01:22 PST
,
Hironori Bono
ap
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Hironori Bono
Comment 1
2009-02-06 01:22:41 PST
Created
attachment 27383
[details]
Proposed fix for 23786 The treatAsSpace() function returns true only when an input character is U+0020, U+000A, U+000D, or U+00A0. So, this |currentAdvance| value becomes 0 only when the character is U+000A and U+000D and this code prevents the UniscribeHelper class from treating a line-break character as whitespace. So, I removed this code.
Alexey Proskuryakov
Comment 2
2009-02-17 03:03:38 PST
Comment on
attachment 27383
[details]
Proposed fix for 23786 r=me
> + * platform/mac/fast/text/international/bidi-linebreak-001-expected.checksum: Added. > + * platform/mac/fast/text/international/bidi-linebreak-001-expected.png: Added. > + * platform/mac/fast/text/international/bidi-linebreak-001-expected.txt: Added. > + * platform/mac/fast/text/international/bidi-linebreak-002-expected.checksum: Added. > + * platform/mac/fast/text/international/bidi-linebreak-002-expected.png: Added. > + * platform/mac/fast/text/international/bidi-linebreak-002-expected.txt: Added. > + * platform/mac/fast/text/international/bidi-linebreak-003-expected.checksum: Added. > + * platform/mac/fast/text/international/bidi-linebreak-003-expected.png: Added. > + * platform/mac/fast/text/international/bidi-linebreak-003-expected.txt: Added.
I'm assuming that these results were generated with Mac WebKit, not with Chromium.
Hironori Bono
Comment 3
2009-02-18 01:01:19 PST
Thank you for your review and comment. (In reply to
comment #2
)
> I'm assuming that these results were generated with Mac WebKit, not with > Chromium.
Yes. These files are created on Mac WebKit. I added them because my fix for
Bug 18335
did not include test results for Mac WebKit and caused a build break on Mac build-bots. I would not like to see any more build breaks caused by my fix.
Dmitry Titov
Comment 4
2009-02-21 01:27:28 PST
Landed:
http://trac.webkit.org/changeset/41122
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug