"Focus window when pointing at overlay" broken in NewUi Preview 3

[matejdro]

Not sure if I did something wrong, but this feature has stopped working for me. I have an overlay set to capture specific window and it does not focus that window (mouse cursor is moving on whatever is currently in focus, while the window stays in the background).

[elvissteinjr]

Windows' focus stealing protection can have a mind on its own sometimes and there are a few restrictions in place. Unfortunately it appears to work just fine on my end right now, so I don't really know what to tell you there.

Has this problem persisted over multiple sessions? What Windows version are you on?

[matejdro]

Windows 10.

It seems to work intermittently, sometimes it does and sometimes it doesn't. This worked fine before I went from stable to NewUi Preview 2 (but it is possible that some external factor has also changed in this time).

I'm also running Desktop+ as administrator (to be able to access elevated windows). Is there maybe an admin-level API that overrides those restrictions?

Are there any logs I can give you to help diagnose this?

[elvissteinjr]

Mhm. The code to focus the window (WindowManager::RaiseAndFocusWindow()) has been unchanged in the NewUI so far, so the behavior should be consistent between the two branches. There is a little bit of trickery already in place with simulating and Alt key press to get open menus to close when SetForegroundWindow() returns failure. Attaching to the current foreground process input queue (AttachThreadInput()) is commonly suggested, but that's actually a really bad idea, so I won't go there.

I'll try to look into it more if there's anything that can be done here. Didn't exactly want to write one of those evil focus stealing applications, but ehh... would be convenient if they let the user decide to free certain apps from restrictions. Would help if it didn't work on my end though. Those restrictions do not get lifted in any way by running as admin or with UIAccess privileges btw. The latter is kinda weird to be honest, but it is how it is. I guess.

Edit: The value of ForegroundLockTimeout may also be relevant, but on machine it has the default value, so I think that may not actually be in use anymore.

[elvissteinjr]

I've prepared a build for you to check out if you would be so kind to do so. There are two relevant changes in it:

• The check for the timeout after a failed focus attempt was wrong. It was reversed, so if you kept trying within 3 seconds by pointing in and outside of a window overlay you might've gotten lucky sometimes. This is fixed now.
• I've added a fallback method of setting the topmost attribute on the target window when setting focus failed. This at least bring the window to the front so a subsequent click can set the focus. The attribute is removed when pointing outside of the overlay. This seems to not be blocked by focus stealing prevention, but requires additional rights when elevated application windows are involved. Elevated mode or UIAccess do the job in those cases, though.

DesktopPlus-NewUI-WindowFocusTest.zip

I believe it should work. But as said, setting the window focus strangely works most of the time on my system... even to steal from elevated applications, so my abilities to test this scenario are limited.

[matejdro]

Original build now also works for me. Whenever it stops working, I will try out your new build, thanks.