Sometimes due to race condition PyBrowser reference lives forever #330
Comments
|
That fix resolved it. Turns out there were the following calls in handlers' callbacks after browser was globally unreferenced in OnBeforeClose: OnResetJavascriptDialogState should still get called, so either make this callback a global client callback as well, or maybe modify behavior of GetPyBrowserIfExists so that it returns PyBrowser object even after onClose, but don't keep a global reference to it in g_pyBrowsers. |
|
Done in commit 36faf91. GetPyBrowser will return an incomplete instance after OnBeforeClose event. This is explained in Browser.md doc and in source comments. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A global reference to PyBrowser object is kept forever and this is causing the app to not quit its message loop after windows were closed, app is still running in background or when run from shell it does not return. This is easily reproduced in hello_world.py example:
Now app will often not terminate its process. CEF message loop is still running. This happens because because len(g_pyBrowsers) > 0.
What happens in app is the following: a PyBrowser is created, then another PyBrowser is created, PyBrowser is closed, and then after browser was closed there is being called one of CEF handlers' callback which calls GetPyBrowser() - which creates PyBrowser again from scratch, as it was closed a moment ago. This reference now lives forever in g_pyBrowsers global list and is causing the message loop to never quit in OnBeforeClose. The solution would be to refactor GetPyBrowser to GetPyBrowserIfExists and return existing or create new PyBrowser only if it was not closed/destroyed previously. All usage of GetPyBrowser would need to be modified, so that it checks whether GetPyBrowserIfExists returned an actual object or a None value.
The text was updated successfully, but these errors were encountered: