The YouTubeAppDock uses its own cookie manager and thus requires a
running CEF instance before creating the dock. Unfortunately creation
of the dock itself and launching the associated browser instance are
coupled in the code.
The UI code to restore browser dock states runs _after_ this code and
unfortunately this is also the only way to ensure that if the user
has closed the YouTubeAppDock before that it stays closed on app
launch (the dock needs to exist in the Widget hierarchy for its state
to be restored).
Alas, outside of Windows, InitBrowserPanelSafeBlock uses a separate
local QEventLoop to block the main thread while still allowing UI
events to be processed to launch a CEF instance.
By this point in the code execution, the primary event loop has not
been started yet, so the event loop launched by
InitBrowserPanelSafeBlock temporarily becomes the main application
event loop, which initializes all Widgets, finds no active window
state for the widgets, and thus treats them as "visible", calls the
showEvent method on every browser dock, which thus loads the associated
websites.
The dock state is restored after all that, which leads to each browser
dock being "shown" (even though the main QApplication hasn't even
started yet), the associated sites are running (including audio and
video output) but then hidden again, which leads to surprising audio
output seemingly coming from "nowhere".
All browser docks call the browser initialization methods synchronously,
which has the benefit of not spinning up a premature event loop, and does
not trigger Qt view state changes before all Widgets have been
initialized. Having the YouTubeAppDock behave the same does thus not
negatively impact UX.
Works around a bug in Qt where setWindowTitle called on a native window
that hasn't been initialised yet causes the title data to be lost,
resulting in the window's title never being set.
Due to a particular... plugin we all know and love, the new
QCefWidget::executeJavascript() function may not actually be present as
it should be. So, we have to verify that it's available, and only use it
in that case.
Apparently the YouTube app dock thing didn't take into consideration the
fact that the user may have the browser source available, but may not
have browser docks available (via the `cef` global). This is because
certain system configurations do not support browser widgets, such as
Wayland on Linux.
(Lain note: There's multiple things I'm unhappy about here. I'm mostly
going to blame myself for multiple reasons.)
