OnJSDialog() MessageBox() blocks window updates

[michaeladamkatz]

I have recently upgraded from cef 3.1650.1539 to 3.2171.1949.

I am on Windows, extending the cefclient sample application. I have an override of ClientHandler::OnJSDialog() in which I call MessageBox().

settings.multi_threaded_message_loop is false.

I an not using CefRunMessageLoop(), but instead have my own loop that calls CefDoMessageLoopWork().

In the new cef, when I drag that message box around over my main window, the main window does not update so I get a smear of message box images on it.

In the older cef I didn't have this problem, using the same code.

My guess is that the window's message/paint processing is blocked during that ClientHandler::OnJSDialog() call. However, I note that when I call MessageBox() at other times (such as in response to the WM_CLOSE message in cefclient_win.cpp), I can drag the dialog box around over the window and the window does update properly underneath.

Any ideas / workaround suggestions? I was thinking I could just set a flag in ClientHandler::OnJSDialog(), and show the message box in the next tick of my main loop, but that of course doesn't work because I can't return from the ClientHandler::OnJSDialog() until I've shown the message box and gotten the user's response.

Update: the same smearing happens with ClientHandler::OnFileDialog(), both when I show the dialog box myself and when I return false to let cef show the dialog box for me.

Update: Just a note to confirm that this problem happens with the cefclient app out of the box. From the Tests menu, choose Begin Tracing and then End Tracing. When the Save As dialog box appears, drag it around and you can see smearing on the main window.

This bug is blocking me from a release.

[me12]

I dont think that I have the solution to your problem but at least some more input:

I had a similar issue with a custom window that I was opening. The issue is in fact that you are blocking the UI-thread while that dialog is open. The window paint happens in that ui thread and thus you won't get any more window paints.

I fixed the problem on my side by exctracting my popup window into a new own thread. No idea if that is possible with the standard dialog boxes though.

Or maybe it is even possible to extract the window paint form the ui-thread?

Another interesting thing is that if you activate desktop composition from your "Visual Effects Performance Options" in windows, the issue goes away. Since Windows uses off-screen-rendering then. (I know this is most likely no solution for you. Just wanted to note it for those who can't reproduce the issue and wonder why.)

[michaeladamkatz]

Associated bug report: https://code.google.com/p/chromiumembed ... 5&sort=-id

me12, thanks for the input. Yes, I thought I could do the dialog box in a different thread, but was hoping a fix might be forthcoming. In the meantime I'm using build 3.1650.1539, which doesn't have this problem.

[kingkwang]

I did this by using custom dialog, which can not move. Disable Main Browser Wnd at the same time.