RESOLVED CONFIGURATION CHANGED 228909
document.fonts.ready stays unresolved
https://bugs.webkit.org/show_bug.cgi?id=228909
Summary document.fonts.ready stays unresolved
Roland Soos
Reported 2021-08-09 00:33:41 PDT
Steps to reproduce: 1. Open https://www.soelvahof.com/kaltern/kaltern/ A lot of time the `document.fonts.ready` stays unresolved. Check its state in the console.
Attachments
Roland Soos
Comment 1 2021-08-09 01:13:06 PDT
It might be related to the fact that window's load event is not happening. `document.readyState` is "complete", but `window.performance.timing.loadEventStart` and `window.performance.timing.loadEventEnd` is 0
Radar WebKit Bug Importer
Comment 2 2021-08-16 00:34:21 PDT
Myles C. Maxfield
Comment 3 2021-09-10 01:28:49 PDT
rdar://82962890 is stopping me from investigating this. Hopefully that bug can be fixed soon so I can investigate this document.fonts bug.
Myles C. Maxfield
Comment 4 2021-09-10 16:48:53 PDT
I modified this bit of code in n2.min.js fonts: new Promise((function(t) { "fonts" in s ? (s.fonts.ready.then(t), h.r("windowLoad", t)) : h.r("windowLoad", t) })) to be this: fonts: new Promise((function(t) { s.fonts.ready.then(function() {debugger;}); "fonts" in s ? (s.fonts.ready.then(t), h.r("windowLoad", t)) : h.r("windowLoad", t) })) and the "debugger" line did get hit in macOS Monterey.
Myles C. Maxfield
Comment 5 2021-09-10 16:54:45 PDT
And, above, when the `debugger;` line gets hit, > document.readyState < "complete" > window.performance.timing.loadEventStart < 1631318004941 > window.performance.timing.loadEventEnd < 1631318004941
Myles C. Maxfield
Comment 6 2021-09-10 21:08:49 PDT
Myles C. Maxfield
Comment 7 2021-09-13 19:06:14 PDT
I'm not able to reproduce this, given the above analysis, so I'm going to mark this as "configuration changed." If this is still happening, please re-open the bug.
Note You need to log in before you can comment on or make changes to this bug.