Bug 217047 - document.fonts.ready is resolved too quickly in first run of module
Summary: document.fonts.ready is resolved too quickly in first run of module
Status: REOPENED
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: Safari 14
Hardware: Mac Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-09-28 02:26 PDT by Andreas
Modified: 2020-10-28 10:14 PDT (History)
8 users (show)

See Also:


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 Details | Formatted Diff | Diff
WIP minimum testcase (3.70 KB, patch)
2020-10-28 06:19 PDT, Tetsuharu Ohzeki [UTC+9]
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas 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.
Comment 1 Radar WebKit Bug Importer 2020-09-29 10:31:35 PDT
<rdar://problem/69753368>
Comment 2 Tetsuharu Ohzeki [UTC+9] 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.
Comment 3 Myles C. Maxfield 2020-10-01 14:19:42 PDT
Cool, thanks! I'll close this then.
Comment 4 Andreas 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).
Comment 5 youenn fablet 2020-10-04 02:46:42 PDT
Andreas, which Safari version did you try it?
Is it reproducing in the latest Safari Tech Preview?
Comment 6 Andreas 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).
Comment 7 youenn fablet 2020-10-04 02:50:07 PDT
Thanks for the confirmation
Comment 8 Andreas 2020-10-04 02:51:46 PDT
I also just tested it in Safari Tech Preview rel. 113 without success.
Comment 9 Tetsuharu Ohzeki [UTC+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.
Comment 10 Ryosuke Niwa 2020-10-08 11:29:50 PDT
Can we add a test so that this won't regress again in the future?
Comment 11 Tetsuharu Ohzeki [UTC+9] 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.
Comment 12 Tetsuharu Ohzeki [UTC+9] 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.
Comment 13 Tetsuharu Ohzeki [UTC+9] 2020-10-28 06:19:30 PDT
Created attachment 412523 [details]
WIP minimum testcase
Comment 14 Tetsuharu Ohzeki [UTC+9] 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?
Comment 15 Tetsuharu Ohzeki [UTC+9] 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).
Comment 16 Tetsuharu Ohzeki [UTC+9] 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])
Comment 17 Tetsuharu Ohzeki [UTC+9] 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.