CefLifeSpanHandler::DoClose not triggering OnBeforeClose

[smessica]

I have a case, where :
- The browser is parented to an application-provided top-level OS window
- Process A creates the parent window
- Process B calls CefBrowserHost::CreateBrowser.
- When process A crash/killed ( not a regular exit ):
--- DoClose() is called, which triggers CloseBrowser(true)

However, OnBeforeClose() is never called.

How to force/guarantee a proper close of the browser object?

Thanks!

[smessica]

Hi Marshall,

I would really appreciate some pointers on this issue.

Thanks!
Shay.

[magreenblatt]

Don't call CloseBrowser from DoClose(). See header file comments on DoClose().

[smessica]

Thanks Marshall.

The root problem here is that the application ( another process ) that provided the parent window got killed.
This caused the OS to release all the HWND tree. So, "CefBrowserWindow" HWND and its children are not longer available.
This means that the mechanism of WM_CLOSE/WM_DESTROY is not available.

So, DoClose is getting called - but I do not see a way to tell CEF to release this object.
Is there a way at this point to reparent the browser to a NULL window?
Can you suggest of some way to trigger the CefBrowser destruction in this unfortunate situation?

[magreenblatt]

You don't need to explicitly trigger browser destruction. The browser should be destroyed and OnBeforeClose() should be called when the browser window receives the WM_DESTROY message via window hierarchy tear-down. Or are you saying the browser window will not receive a WM_DESTROY message in your use case?

[smessica]

yes, that is the problem. When the separate process is killed abruptly, the OS clears the HWNDs without triggering any action.
And we can not post a WM_DESTROY message as the window is already invalid.
We detect the IPC channel drop and issue a CloseBrowser, which triggers the DoClose.

[magreenblatt]

yes, that is the problem. When the separate process is killed abruptly, the OS clears the HWNDs without triggering any action.
And we can not post a WM_DESTROY message as the window is already invalid.
We detect the IPC channel drop and issue a CloseBrowser, which triggers the DoClose.

Are you calling CloseBrowser(true) when the channel is dropped? If not, why?

[smessica]

I do

[magreenblatt]

The lack of a WM_DESTROY message is an untested state. There's likely a bug resulting from that.

[smessica]

Looking via Spy++, I see that the only messages those windows get are WM_NCDESTROY ( in particular no WM_DESTROY ).
So, it seem that some fallback cleanup is needed on that event.
Or, to have the CloseBrowser(true) to perform the actual work in case, the window is no longer valid.