sub process steals focus?

[biomerge]

Hi,

I have a focus problem when some sub processes are spawned. When I have a dialog box open in the main program (browser process) I sometimes need to press the enter button twice or more in order for the default button to be triggered. I do not have this issue when the CEF sub processes are disabled. It seems like the sub processes are stealing focus (even though no window is shown). I have no issues with displaying web pages or even JS integration, only this focus problem. Any command line arguments I could set or other hints to fix this? My OS is Windows 10.

[magreenblatt]

Please provide the following details:

• What CEF version?
• Are you using windowed or off-screen rendering?
• How are you running the CEF message loop?
• How are you creating the dialog box? Is it modal?
• Are you activating/focusing the dialog box on creation?
• What is the relationship between the dialog box and the browser window? Is the browser window visible? Is the dialog box above the browser window?
• What do you mean by "I do not have this issue when the CEF sub processes are disabled"?

[biomerge]

Ok, here is some more information:

Cef verison: 78.3.9
I integrated the CEF message loop in my MFC message loop using "CefDoMessageLoopWork".
The dialog box is modal. It has a default pushbutton that should be triggered by the "enter" key.
There is no browser window created yet, and thus no renderer subprocesses are active yet. However, "CefInitialize" was called already which spawns about two (non renderer) sub processes.
So there is no relationship between the browser window (not in existence yet) and the dialog box at all. If I remove the call "CefInitialize" and thus block the spawning of sub processes,
then the dialog box performs normally again (the "enter" button triggers the default button at first try). It's clear that the existence of the sub processes affect the behavior of the dialog box default button. Whether this is a focus issue was just an assumption. It might as well be something else as the "Window focus logger" program seems to indicate that the focus is never removed from the dialog box to another window. That makes sense because the sub processes show no window at all. I created a separate subprocess executable. However, this is just a very basic win32 program that never displays a window. See code below:

Code: Select all

int APIENTRY _tWinMain(_In_ HINSTANCE /*hInstance*/,
                     _In_opt_ HINSTANCE /*hPrevInstance*/,
                     _In_ LPTSTR    /*lpCmdLine*/,
                     _In_ int       /*nCmdShow*/)
{
   Cef cef;
   return cef.Initialize();   //return value of ::CefExecuteProcess
}

So what happens sometimes when pressing the "enter" key? Windows generates the same error sound as when you do a mouse click on an underlying window (you must first take care of the modal dialog box) and then nothing happens. Sometimes when pressing "enter" the default push button does get triggered and the dialog closes (as it should). This inconsistent behavior does not occur when there are no CEF sub processes running. The whole time the dialog box seems to be the active window (the border is highlighted), so no visual clues there.
My first thought was that maybe upon spawning of the sub process some additional command line argument should be added, but I'm not really sure.

[magreenblatt]

Are you calling CefDoMessageLoopWork while the dialog box is visible?

[biomerge]

Hey magreenblatt. Thanks for the investigation. It appears to be a combination of dubious legacy dialog implementation and the CEF subprocesses. For some reason they have chosen to implement the WM_KICKIDLE message with a "return TRUE" and this triggers a flood of these WM_KICKIDLE messages. This used to work fine, but breaks (with the described behavior) in combination with the CEF subprocesses. Stopping the flood of WM_KICKIDLE messsages fixed it for me.
So, not really a CEF issue, even though it was triggered since the introduction of the CEF subprocesses. However any sub process probably would have triggered that.

Thanks again!