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.
<rdar://problem/69753368>
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.
Cool, thanks! I'll close this then.
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).
Andreas, which Safari version did you try it? Is it reproducing in the latest Safari Tech Preview?
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).
Thanks for the confirmation
I also just tested it in Safari Tech Preview rel. 113 without success.
I confirm Safari TP 114 (rev 265893-267325) has not fixed yet. Some commits after rev 267325 would fix this.
Can we add a test so that this won't regress again in the future?
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.
(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.
Created attachment 412523 [details] WIP minimum testcase
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?
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).
(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])
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.