document.fonts.ready stays unresolved

• Component: Page Loading
• Status: RESOLVED CONFIGURATION CHANGED

[Roland Soos]

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.

[Roland Soos]

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]

<rdar://problem/81969526>

[Myles C. Maxfield]

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]

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]

And, above, when the `debugger;` line gets hit,

> document.readyState
< "complete"
> window.performance.timing.loadEventStart
< 1631318004941
> window.performance.timing.loadEventEnd
< 1631318004941

[Myles C. Maxfield]

<rdar://problem/81969526>

[Myles C. Maxfield]

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.