Repository navigation
Initialize dock later to bypass startup crash - #554
Conversation
|
Change seems good enough for a quick band-aid to me. My current working theory is that the If attached and closed, the dock state of all docks will be restored 3x during OBS startup, which means the chat dock will be closed twice and Qt will also emit a I'd suggest a commit message such as:
|
46f7f07 to
73b8926
Compare
Defers the scheduling of browser initialisation to the next iteration of the Qt event loop to allow dock state restoration to finish before CEF will attempt to attach its browser window to the dock's widget hierarchy. Attempting to initialize a browser immediately will lead to CEF crashing during the same attempt on Windows, as the CEF event loop runs independently and thus might interact with incomplete widget hierarchy.
73b8926 to
38dd02c
Compare
Description
This one's fun.
This delays CEF & browser dock initalisation on startup to avoid a potential crash on startup in specific configurations.
Luckily this is an edge case most users won't run into.
Unfortunately I didn't catch this sooner, as I usually don't close my chat dock. Originally I thought this was tied to the "Closing Dockable Window" dialog (when closing for the first time), but seems that was a red herring.
Motivation and Context
Reproduction Steps:
When Qt attempts to apply the saved dockState, it does so by closing the dock too fast, so CEF panics.
Stack trace in the event loop:
How Has This Been Tested?
Reproduction steps above on Windows 10.
Without this fix, a crash occurs. With this fix, the Chat dock is correctly hidden, other docks initialise fine, and there's no crash.
Types of changes
Checklist: