With recent changes to the application shutdown logic, events had to
follow a very strict order as certain elements of shutdown code
depend on other elements not being deallocated prematurely.
This turned the (correct) order of events on macOS upside down and
lead to crashes either when the app was quit from within or when
terminated by the OS.
The fix incorporates multiple elements:
* Removal of the custom "Quit" menu item on macOS to use the default
implementation of Qt's platform plugin.
* Soft-revert (via preprocessor conditionals) parts of the updated
shutdown logic to prevent emitting recursive shutdown events.
* Handle main window close event by simply emitting a "quit" event
on the application instance.
* Update POSIX signal handlers to also simply emit a "quit" event.
In combination these changes reduce the number of different code paths
taken during shutdown:
* Closing the app via the menu item, menu item shortcut, or initiated
by AppKit (OS shutdown/reboot, or quit via Dock/Finder) will emit an
AppKit "terminate" event for orderly shutdown.
* Closing the main window or sending an appropriate POSIX signal
triggers the "terminate" event indirectly by emitting the "quit"
event on the application instance.
Either way a "close" event to the main window happens before the
event loop is terminated and the application instance is torn down
(either directly, or indirectly via Qt's "closeAllWindows" function in
response to "terminate"). The order of events thus is always:
0. Terminate event by AppKit (except when closing the main window)
1. Closing of main window
2. Termination of browser docks
3. Deallocation of main window
4. Termination of application
5. Deallocation of application
NOTE: All this only applies to macOS. The shutdown order and procedures
on Windows and Linux are unchanged.
When the main window is closed and with it the application state is torn
down, browser panels need to be explicitly removed before the the CEF
instance used by the application is shut down itself.
For service-based docks this happens as part of the "reset" of the
"auth" pointer (and thus its destructor), for user-created browser
panels this is achieved by the call to "ClearExtraBrowserDocks".
Because the Youtube app dock is a special browser panel that is created
conditionally, but potentially exists globally, it also has to be
closed this way (if it was created).
Otherwise CEF will force-close the underlying browser host instance as
part of its own shutdown and also deallocate the native window used
by the browser. When the QCefWidget then attempts to detach the
native window from the view hierarchy (to avoid this operation from
potentially closing the root window it is anchored to), it will either
attempt to access a CrFatZombie object (and crash) or access deallocated
memory (and also crash).
Improves app shutdown in a few ways, including separating out different
pieces of the OBSBasic close handler into their own functions.
Removes the crash handler sentinel earlier when the main window is closed,
preventing unclean shutdown warnings when a plugin causes issues. While not
ideal, the dialog is not useful when we cannot specify which plugin caused the
problem.
Increases shutdown priority of the main application so that when OBS interrupts
the session ending, CEF is not closed at the same time. This fixes a crash.
Additional safeguards and event handling to try to ensure a smoother shutdown.
The default of 2500 kbps was chosen 10 years ago and times have changed.
Logs and forums posts show that many users of OBS for recording don't
change their bitrate and end up with a 2.5 mbps recording which looks
terrible.
Now that service bitrate enforcement exists, this will be automatically
capped to the maximum bitrate for streaming services, so the only time
this should result in a problem is if the user's upload speed is the
limiting factor, hopefully rarer these days with increasing internet
speeds.
For phase 1 of the plugin manager, the ability to toggle off/on plugins
to be loaded at launch is provided.
This commit adds a new Plugin Manager dialog which can be accessed from
the Tools menu, which shows a list of all installed 3rd party plugins
with a checkbox to toggle them off or on. If a change is made, the user
is prompted to restart OBS. To allow this, the plugin manager uses a
json based config file stored in the OBS config directory. Additionally
for sources in the source tree, a sample UI has been provided that
indicates any sources whose parent module is disabled, by turning its
title red.
Updates include:
* Use of CrashHandler to provide automatic uploads of the most recent
crash log if an unclean shutdown was detected and it has not been
uploaded yet.
* Detection and handling of unclean shutdowns is delegated entirely to
the CrashHandler class
* Use of OBSLogReply has been replaced with the LogUploadDialog, which
asks for confirmation before new uploads of log files (confirmation is
skipped for files with available upload URLs already - only available
for crash logs with this change)
Architectural changes:
* OBSApp is the layer responsible for application launch and shutdown
states, as well as crash logs and application logs
* The actual handling is delegated to purpose-made classes which OBSApp
owns instances of
* OBSBasic in turn refers to OBSApp for all this functionality, and can
subscribe/connect to appropriate events exposed by OBSApp to this
purpose
* Implementation details (like the existence of the CrashHandler class)
are not exposed to OBSBasic or the LogUploadDialog
The amount of changes for normal log file upload have been purposefully
limited. A proper refactoring of the application log file handling will
move this code out of OBSBasic as well.
With the removal of all legacy code paths, obsconfig.h always exists and
the compile definition always gets set. As such, it's no longer
necessary to check for it.
As removing the definition itself could be seen as a breaking change,
this simply moves the definition to pc.in and cmake.in files for now to
preserve the value for plugins that might expect this to be set. We may
remove the definition entirely in a later release.
To emit frontend events early during OBS' initialization, the
disableSaving state variable needs to be "falsy" (as events will not be
emitted otherwise).
The code path taken for generating a new fallback scene collection
has disableSaving decremented to "enable" saving (and thus frontend
events) already, so it's just the code paths for existing collections
that need this workaround.
Emitting the scene changed and preview scene changed events when a
fallback scene collection has been created has side-effects when
OBS Studio is set to studio mode and can lead to potential crashes,
as the studio mode is still in an invalid state at this point.
