WM_NCHITTEST and HTTRANSPARENT block input from message loop

Question

We have a user-defined dashboard. You can add several components to this window. Some windows are browser controls (ActiveX controls created using CLSID_WebBrowser). This browser control can display content from various sources on the internal network.

To avoid blocking the application, each browser control is placed in its own thread. The reason here was that the ActiveX Webbrowser control is hosted in the STA and only downloads and displays data when the message loop starts, and this can block other parts of the user interface.

So, we have one parent window containing the child windows for managing the list of types, control tree, statics, and group boxes mixed with some browser controls. In addition to managing the browser, all controls belong to the same user interface thread. But the threads use one input queue, and AttachThreadInput was executed for each thread to bind it to the main thread.

Now we are faced with the following problem:

When a user creates his screen with a group box and a web control inside it. the application is blocked when the user moves the mouse over the browser control and presses or uses the mouse wheel. The application blocks and does not accept any additional data. If you minimize the application and activate it again, you can work and the input is accepted again.

Causes

With the debugger and spy ++, we found out that any mouse event causes WM_NCHITTEST to be sent to the group field. The group returns HTTRANSPARENT. But the main window has a different thread. We see that an infinite loop occurs with the WM_NCHITEST message in the group field, and the input is blocked until this loop is interrupted (minimizing by showing the desktop).

We can read in the documentation that WM_NCHITTEST and HTTRANSPARENT are limited to windows of the same stream. And I can find 2 more articles on the net that describe the same or similar issue.

A simple solution

A simple solution is to simply ensure that browser controls are never covered by group box or static control. Therefore, changing the Z-order is simple and works (the group box should follow the windows of another thread in the Z-order)

Question

I would be wondering if there is another way around this problem. Or, if there is a way to prevent such blocking of the input queue. Or if someone knows what happens inside when this WM_NCHITTEST should process windows from different threads.