Bug 220488 - Make fast/text/international/complex-character-based-fallback.html more robust by migrating it to be a reftest instead of a DRT test
Summary: Make fast/text/international/complex-character-based-fallback.html more robus...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Myles C. Maxfield
URL:
Keywords: InRadar
Depends on:
Blocks: 219105
  Show dependency treegraph
 
Reported: 2021-01-08 16:41 PST by Myles C. Maxfield
Modified: 2021-01-12 15:13 PST (History)
2 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Myles C. Maxfield 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
Comment 1 Myles C. Maxfield 2021-01-08 16:43:16 PST
Created attachment 417314 [details]
Patch
Comment 2 Darin Adler 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?
Comment 3 Darin Adler 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.
Comment 4 Myles C. Maxfield 2021-01-08 16:54:40 PST
Created attachment 417316 [details]
Patch
Comment 5 Myles C. Maxfield 2021-01-08 16:57:29 PST
Created attachment 417317 [details]
Patch
Comment 6 Myles C. Maxfield 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?).
Comment 7 Myles C. Maxfield 2021-01-08 16:58:51 PST
<rdar://problem/70556068>
Comment 8 Darin Adler 2021-01-08 17:10:52 PST
Comment on attachment 417317 [details]
Patch

Are we always guaranteed to have the Latha font present?
Comment 9 Myles C. Maxfield 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.
Comment 10 EWS 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].