Since the Launch Services database is provided to the WebContent process by the Network process, it makes sense to wait for the database when we're certain that the Network process is running. This should fix main thread hangs in the cases where we before started waiting for the database before the Network process had launched. To support this move, we also need to delay the initialization of accessibility in NSApplication, since that depends on having the database available. This is now being done in WebPage::platformInitializeAccessibility, which is a natural place for this initialization to take place.
Created attachment 458880 [details] Patch
Created attachment 458881 [details] Patch
Created attachment 458883 [details] Patch
<rdar://92107043>
Comment on attachment 458883 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=458883&action=review r=me > Source/WebKit/WebProcess/WebProcess.cpp:1201 > + // The NSApplication initialization is being done in [NSApplication _accessibilityInitialize] No need to call accessibilityInitialize here.
(In reply to Geoffrey Garen from comment #5) > Comment on attachment 458883 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=458883&action=review > > r=me > > > Source/WebKit/WebProcess/WebProcess.cpp:1201 > > + // The NSApplication initialization is being done in [NSApplication _accessibilityInitialize] > > No need to call accessibilityInitialize here. Looking closer, this actually seems to be inside a comment. Line wrapping made it look like a separate statement when we last looked at this. Thanks for reviewing!
Committed r293892 (250350@main): <https://commits.webkit.org/250350@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 458883 [details].
Haha, that's the last time I review a patch on my phone! :P
(In reply to Geoffrey Garen from comment #8) > Haha, that's the last time I review a patch on my phone! :P :)