Bug 217047

Summary: document.fonts.ready is resolved too quickly in first run of module
Product: WebKit Reporter: Andreas <andreas>
Component: CSSAssignee: Nobody <webkit-unassigned>
Status: REOPENED    
Severity: Normal CC: andreas, cdumez, ggaren, heycam, mmaxfield, rniwa, tetsuharu.ohzeki, webkit-bug-importer, youennf
Priority: P2 Keywords: InRadar
Version: Safari 14   
Hardware: Mac   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=174030
https://bugs.webkit.org/show_bug.cgi?id=225790
Attachments:
Description Flags
Test which measures the width of a textual element in a loaded font.
none
WIP minimum testcase
none
WIP minimum testcase none

Andreas
Reported 2020-09-28 02:26:17 PDT
Created attachment 409874 [details] Test which measures the width of a textual element in a loaded font. document.fonts.ready is resolved too quickly when run inside a module the first time the page is loaded. On subsequent reloads the font is effectively ready (cached?). The attachment demonstrates this by loading a (Google) font and trying to determine the width of a span filled with text. The first time the page is loaded the width returned is the one from 'monospace' font and not the loaded one. On second reload the returned width is correct.
Attachments
Test which measures the width of a textual element in a loaded font. (1.90 KB, text/html)
2020-09-28 02:26 PDT, Andreas 		no flags
Details
WIP minimum testcase (3.45 KB, patch)
2020-10-09 09:30 PDT, Tetsuharu Ohzeki [UTC+9] 		no flags
DetailsFormatted DiffDiff
WIP minimum testcase (3.70 KB, patch)
2020-10-28 06:19 PDT, Tetsuharu Ohzeki [UTC+9] 		no flags
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2020-09-29 10:31:35 PDT
<rdar://problem/69753368>
Tetsuharu Ohzeki [UTC+9]
Comment 2 2020-10-01 10:40:19 PDT
I'm not confident that, but I seem this has been fixed at least in rev 267835 which I downloaded from https://webkit.org/build-archives/ for macOS Catalina and launch by run-webkit-archive.
Myles C. Maxfield
Comment 3 2020-10-01 14:19:42 PDT
Cool, thanks! I'll close this then.
Andreas
Comment 4 2020-10-04 02:07:59 PDT
I just tested it with the provided test example:https://bugs.webkit.org/attachment.cgi?id=409874 and it's not resolved. I suggest to re-open the issue and to test it with the provided example (comments are inside the source code).
youenn fablet
Comment 5 2020-10-04 02:46:42 PDT
Andreas, which Safari version did you try it? Is it reproducing in the latest Safari Tech Preview?
Andreas
Comment 6 2020-10-04 02:49:11 PDT
I just tested it in rev 267835 as suggested by tetsuharu.ohzeki@gmail.com I had to adapt the test as I wasn't able to access the inspector: so the output had to be rendered into the DOM instead of console. But it failed (first run only, subsequent runs are ok).
youenn fablet
Comment 7 2020-10-04 02:50:07 PDT
Thanks for the confirmation
Andreas
Comment 8 2020-10-04 02:51:46 PDT
I also just tested it in Safari Tech Preview rel. 113 without success.
Tetsuharu Ohzeki [UTC+9]
Comment 9 2020-10-08 11:09:53 PDT
I confirm Safari TP 114 (rev 265893-267325) has not fixed yet. Some commits after rev 267325 would fix this.
Ryosuke Niwa
Comment 10 2020-10-08 11:29:50 PDT
Can we add a test so that this won't regress again in the future?
Tetsuharu Ohzeki [UTC+9]
Comment 11 2020-10-09 09:30:54 PDT
Created attachment 410942 [details] WIP minimum testcase I edit the test case to make it minimum. I confirm this would fails in Safari 14.0 but this passes on the Mini Browser (rev 268202) built on my local machine.
Tetsuharu Ohzeki [UTC+9]
Comment 12 2020-10-09 09:35:43 PDT
(In reply to Tetsuharu Ohzeki from comment #11) > Created attachment 410942 [details] > WIP minimum testcase > > I edit the test case to make it minimum. I confirm this would fails in > Safari 14.0 but this passes on the Mini Browser (rev 268202) built on my > local machine. With MiniBrowser launched by run-minibrowser, I reset caches by menu's "Debug" -> "Clear WebSite Data". I seem this bug is fixed bug in the latest trunk. However, sadly, this bug is reproduce randomly even if with the latest trunk's MiniBrowser. After clearing caches, reloading the page multiple times, this bug sometimes reproduce.
Tetsuharu Ohzeki [UTC+9]
Comment 13 2020-10-28 06:19:30 PDT
Created attachment 412523 [details] WIP minimum testcase
Tetsuharu Ohzeki [UTC+9]
Comment 14 2020-10-28 06:24:10 PDT
Comment on attachment 412523 [details] WIP minimum testcase View in context: https://bugs.webkit.org/attachment.cgi?id=412523&action=review > LayoutTests/fast/css/font-face-set-ready-regression-expected.txt:2 > +a: 1600 As an expected case, this should be 960. If the I ran this test manually in Safari/MiniBrowser with clearing caches, this will be 960. However, WebKitTestRunner will dump 1600. This is mysterious behavior but I don't have any good idea to reproduce this test in WebKitTestRunner too... Do you have any good idea?
Tetsuharu Ohzeki [UTC+9]
Comment 15 2020-10-28 06:31:34 PDT
Furthermore, I observe that this bug is reproducible again in Safari TP 115 running on both of macOS 10.15.7 and macOS 11.0 Beta (20A5395g).
Tetsuharu Ohzeki [UTC+9]
Comment 16 2020-10-28 06:41:10 PDT
(In reply to Tetsuharu Ohzeki from comment #15) > Furthermore, I observe that this bug is reproducible again in Safari TP 115 > running on both of macOS 10.15.7 and macOS 11.0 Beta (20A5395g). I tested them with the original test case (attachment 409874 [details])
Tetsuharu Ohzeki [UTC+9]
Comment 17 2020-10-28 10:14:05 PDT
With the WIP minimum testcase (attachment 412523 [details]), I confirmed followings with rev 269096: * This is reproducible on MiniBrowser with release build. * But this is not reproducible on MiniBrowser with debug build.
Note You need to log in before you can comment on or make changes to this bug.