Page MenuHome

Child windows do not lose focus properly when xmouse tracking (no auto-raise) is enabled
Needs Triage, NormalPublic


System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 1650/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 462.59

Blender Version
Broken: version: 2.93.0, branch: master, commit date: 2021-06-02 11:21, hash: rB84da05a8b806
Worked: (newest version of Blender that worked as expected)

Short description of error
Child windows do not lose focus properly when xmouse tracking (no autoraise) is enabled

Exact steps for others to reproduce the error

Updated to 2.93 just now and ran into this.

  1. I altered the focus system of windows 10 to follow the mouse cursor and disabled the auto raise function as described here:

  1. Create a child window that slightly overlaps the main window( for visual feedback as to what is focussed).
  1. Hover the mouse over the child window until win10 switches focus to it, then move it back to the main window.
  1. Child window does not lose focus until i click on my main window again. You can verify the discrepancy by adding a second main window that does lose focus properly. `
  • Curiously, adding a third window, a main one, does get focussed properly when the last window-in-focus was the child window, so it is only the initial main window that is affected.

Event Timeline

Richard Antalik (ISS) changed the task status from Needs Triage to Needs Information from User.Thu, Jun 10, 7:18 PM

There have been changes in 2.93 window handling. Can you repeat all steps but using actual mouse clicks and see if behavior is the same?
If it's the same than this is same issue as T89021


The issue in my case is not with the window staying on top(I thought that was intended behavior!). My only issue is that I have to click on the main window to regain focus again, even though this should not be the case due to how i configured windows 10. The task you referred to has a slightly misleading title(imho).

To prevent any confusion I shall elaborate. The user who created task T89021 experiences the newly added behavior of child windows on windows platforms as a bug, but if i'm not mistaken in my interpretation of it, that user thinks the render wndow ( which is a child window ) should not stay on top. The title is misleading because in the context set by the user, focus does not mean where windows 10 will let you perform work(work as in typing/scrolling). Instead, he describes the top-most window as the in-focus window. I'm pretty sure that user can still work in his main window even though the render window stays on top. So it is NOT a duplicate.

It's a bit hard to describe why this is an issue worth posting but i'll try that too:

In 2.92 and earlier versions, I was able to hover the mouse from window to window and use hotkeys without clicking in a window first, since 2.93 this is not possible anymore when using child windows. But interestingly, it only doesn't work on windows that are actually related, and only, from child to parent.

This video illustrates the issue pretty well. Except for the render window, they are all main windows. The render child window is a child of the left main window. The shadows around a window indicate which window is your "active" or focussed window, regardless of which one is on top.

Richard Antalik (ISS) changed the task status from Needs Information from User to Needs Triage.Mon, Jun 14, 12:43 AM

I will check this, but it may be that window doesn't receive event as expected and then it will be up to developer to decide if this is valid bug, as this may not be deemed as usual environment.

Also I have question regarding steps from
Is it required to modify windows registry to test this?

Sadly, yes. I fully understand if it won't get fixed therefore. I got around it by switching to a second main window so i'm unhindered by it to be honest.

Thank you for your time though!