No relayouting when dragging to monitor with different zoom and browser is opened

[HeikoKlare]

Description
When a browser is open in the workbench window, dragging the window to a monitor with a different zoom will only relayout the contents when the mouse button is released.

Reproduction
Open a fresh SDK, such that the welcome view is open (or just reopen manually or any browser like the "Internal Browser" view). Drag the window to a monitor with different zoom and keep the mouse button pressed. Only once you release the mouse button, the window contents will relayout.

Expected Behavior
Even with a browser open, the window should relayout while dragging to a monitor with different zoom.

Additional knowledge
This is probably related to an embedded window handle. Either this prevents some event processing or maybe the counter for the DPI change event does, for some reason, not decrement to 0 here, such that the even processing does not trigger a relayout.

[HeikoKlare]

Just debugged this and turns out that the async handler in Control#sendZoomChangedEvent is not executed at all when dragging a workbench window to a different monitor until the mouse button is released. So it's not about missing decrement (as guessed in the original post) but really about not async message processing happening while dragging in case a browser is open.

[HeikoKlare]

Turns out that async processing of DPI change events does not occur by ordinary event queue processing (the event queue is not even spinned when dragging a window at all, i.e., not Display#readAndDispatch() is exected then) but by an OS callback for a message with code OS.MSGF_MOVE with property hookMsg.message == OS.WM_NULL leading to async messages being processed by this strange hook:
https://github.com/eclipse-platform/eclipse.platform.swt/blob/d4ddd4cb9862ac54b025c08700bdff357369c7cb/bundles/org.eclipse.swt/Eclipse%20SWT/win32/org/eclipse/swt/widgets/Display.java#L3484-L3489

For some reason, this does not happen when a browser is open.
But it's strange and unexpected in general, that the DPI change event processing happens via this call instead of an ordinary event queue processing.

[amartya4256]

Few findings:

• https://stackoverflow.com/questions/71918222/dispatchmessagew-blocks-execution-when-moving-the-window The OS:DispatchMessage call in Display:readAndDispatch is blocked until the cursor drops the window.
• There are 2 places from where async tasks are executed using Display:runAsyncMessages method - msgFilterProc and readAndDispatchMessage. Since, the call in Display:readAndDispatch is blocked by OS:DispatchMessage, the processing happens using Display:msgFilterProc. If you comment out the code if (runAsyncMessages (false)) wakeThread ();, the behaviour for with and without browser is the same while scaling because they both get blocked by Display:DispatchMessage and execute using return isDisposed () || runAsyncMessages (false); in Display:readAndDispatch. That's why while dragging it doesn't work with readAndDispatch. However, if you just change the zoom of the monitor, in this case no blocking happens at OS:DispatchMessage and hence the scaling is processed using readAndDispatch
• Since, the way readAndDispatch has been implemented, it makes it incompatible to work with while dragging with the current state because of the blocking OS:DispatchMessage.

Also found out that when we have a browser active, the hookMsg.message is not zero, but if I remove the check, it works fine and everything scales. I realized that WM_NULL is sent by the OS when it doesn't want the consumer to do anything. https://learn.microsoft.com/en-us/windows/win32/winmsg/wm-null

I tried adding a control = findControl(hookMsg.message); control.embedsWin32Control() but turns out, it can't resolve the control when we need it.

I cannot understand the logic behind putting a hookMsg.message == OS.WM_NULL check.