WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
220488
Make fast/text/international/complex-character-based-fallback.html more robust by migrating it to be a reftest instead of a DRT test
https://bugs.webkit.org/show_bug.cgi?id=220488
Summary
Make fast/text/international/complex-character-based-fallback.html more robus...
Myles C. Maxfield
Reported
2021-01-08 16:41:13 PST
Make fast/text/international/complex-character-based-fallback.html more robust by migrating it to be a reftest instead of a DRT test
Attachments
Patch
(554.72 KB, patch)
2021-01-08 16:43 PST
,
Myles C. Maxfield
no flags
Details
Formatted Diff
Diff
Patch
(556.01 KB, patch)
2021-01-08 16:54 PST
,
Myles C. Maxfield
no flags
Details
Formatted Diff
Diff
Patch
(556.06 KB, patch)
2021-01-08 16:57 PST
,
Myles C. Maxfield
no flags
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Myles C. Maxfield
Comment 1
2021-01-08 16:43:16 PST
Created
attachment 417314
[details]
Patch
Darin Adler
Comment 2
2021-01-08 16:45:25 PST
Comment on
attachment 417314
[details]
Patch Could we convert the HTML files to UTF-8 instead of UTF-16?
Darin Adler
Comment 3
2021-01-08 16:52:45 PST
Can do it with this: iconv -f utf-16 -t utf-8 LayoutTests/fast/text/international/complex-character-based-fallback.html > temp.html mv temp.html LayoutTests/fast/text/international/complex-character-based-fallback.html Then probably need to add <meta charset="UTF-8"> to make sure it gets handled as UTF-8.
Myles C. Maxfield
Comment 4
2021-01-08 16:54:40 PST
Created
attachment 417316
[details]
Patch
Myles C. Maxfield
Comment 5
2021-01-08 16:57:29 PST
Created
attachment 417317
[details]
Patch
Myles C. Maxfield
Comment 6
2021-01-08 16:58:21 PST
The new files are UTF-8, but unfortunately bugzilla still thinks the test is a binary file (perhaps because the original version is UTF-16?).
Myles C. Maxfield
Comment 7
2021-01-08 16:58:51 PST
<
rdar://problem/70556068
>
Darin Adler
Comment 8
2021-01-08 17:10:52 PST
Comment on
attachment 417317
[details]
Patch Are we always guaranteed to have the Latha font present?
Myles C. Maxfield
Comment 9
2021-01-12 14:56:59 PST
(In reply to Darin Adler from
comment #8
)
> Comment on
attachment 417317
[details]
> Patch > > Are we always guaranteed to have the Latha font present?
No. Unfortunately, I don't think there is a way to test font fallback without explicitly naming individual fonts. So, this patch makes us go from a test that was brittle and relied on an individual font, to a test that's less brittle and still relies on an individual font. A progression to be sure, but not perfect. I don't actually think adding an internals function to make sure that the right fallback functions are getting called would actually be better, as those fallback functions are just as much an implementation detail as these system fonts. Indeed, the presence of these language-support fonts likely changes less often than we change our font fallback code. So, with this patch, we're at a local maximum, and my claim is that our local maximum is also a global maximum.
EWS
Comment 10
2021-01-12 15:13:20 PST
Committed
r271419
: <
https://trac.webkit.org/changeset/271419
> All reviewed patches have been landed. Closing bug and clearing flags on
attachment 417317
[details]
.
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