search

joelpurra / xmouse-controls

Microsoft Windows utility to manage the active window tracking/raising settings. This is known as x-mouse behavior or focus follows mouse on Unix and Linux systems.
https://joelpurra.com/projects/X-Mouse_Controls/
GNU General Public License v3.0
229 stars 18 forks source link

Behavior appears to have changed with a recent Windows update #23

Closed BatmanAoD closed 3 years ago

BatmanAoD commented 3 years ago

I've been using xmouse-controls to emulate X "focus follows mouse" on Windows 10, i.e., activating windows without raising them. Recently, however, windows are always raised when they are activated, whether or not the "raise window" checkbox is selected in xmouse-controls.

I don't know if this is an issue with my system or if it's due to a recent change in Windows; and if it's the latter, I don't know whether or not it's fixable. I was recently updated to version 21H1 (OS build 19043.1110, experience pack 120.2212.3920.0), so if anyone else has this issue, hopefully they will see this issue and can give another data point on whether an update is the culprit.

binki commented 3 years ago

Hi @BatmanAoD ,

What programs are these windows which raise themselves from?

I use latest Windows (on Windows 11 Insider builds now, build 22000.160) as well as 21H1 (build 19043.1165) and I do not experience that behavior. I can, for example, mouse over Notepad when it is mostly covered by Firefox and it will receive focus without raising itself.

However, as noted in the Notes section of the website, MDI (Multiple Document Interface) applications (such as Visual Studio or things based on its shell like SSMS) will raise themselves when focused, which is quite annoying. But that is the application itself raising itself, so there is nothing that can be done about that. Those applications themselves would need to be changed to better support Windows’s focus follows mouse feature.

BatmanAoD commented 3 years ago

@binki All programs -- terminal windows (Alacritty & PowerShell), Firefox, Slack, Discord, VS Code, Notepad, etc. This behavior definitely started recently; previously everything worked as expected.

I know there are some differences between the 11 builds and the 10 builds, so I'm not ready to rule out a Windows change just yet, but maybe it's a bug that's been fixed in a later build, and I just have to wait for the fix to trickle down to the Beta channel.

binki commented 3 years ago

@BatmanAoD Have you opened XMouse-controls and toggled the settings back and forth, applying in-between, to verify that it is set correctly? Do you use any third party window management software, etc.? I don’t see the behavior even when running a similar Windows build as your (the stable build I run is 19043.1165). I expect the issue to be local to your system—I bet you would not observe it on a fresh install (or if you created a new user profile—that might be something to try in narrowing things down).

Please do share if you figure it out and whether or not it reproduces!

BatmanAoD commented 3 years ago

Yes, I toggled/applied the controls quite a bit to make sure that the relevant registry entries hadn't just been overwritten somehow. No, I do not use any third party window management software. My computer is managed by my employer, so I don't know if I can create a new account, but I'll try that; thanks.

joelpurra commented 3 years ago

@BatmanAoD: just tested with a couple of windows from various applications on Windows 10 Pro (version 21H1, build 19043.1165, experience pack 120.2212.3530.0), and I don't experience any change. Works the same as before.

I agree with @binki's tips and questions. I'll also add that with regards to #15, other computers with the same Microsoft account may affect x-mouse settings by syncing them (presumably because the user registry is synced). I have no experience with this though, as I don't use such an account. Unsure if your particular company account has a similar sync feature but seems likely, right? Might be something to think about, if you use/have used more than one computer.

BatmanAoD commented 3 years ago

I was able to create a new account to test with, and indeed, activating windows without raising them worked just fine on the new account! My user account is indeed linked to my Microsoft account, and I did just get a new computer that I believe I signed in on as well, so maybe that somehow caused the issue.

binki commented 3 years ago

I don’t expect using a synchronized account in and of itself to have an effect. For me, that merely meant that I don’t need to download XMouse-Controls or manually edit the registry on any new computer I use my MSA with ;-).

However, if the account was added as a “school or work” account or you have “enrolled” your device, then that probably lets group policy and things like that to be applied. I don’t see any obvious group policy option for this, but maybe that enterprisey stuff lets them overwrite/overlay/force specific registry keys? No idea how that stuff works x.x. If that is the issue, it is probably done accidentally or indirectly.

BatmanAoD commented 3 years ago

I disabled and re-enabled the native Windows ease-of-access "Activate a window by hovering over it with the mouse" setting, then re-enabled the X-Mouse Controls version. This worked, fixing my problem (windows activate without being raised). I'm guessing that there was a bad bit set in the registry somehow, and the native Windows toggle cleared it.

BatmanAoD commented 3 years ago

It may be worth adding this fix to the tips/workarounds section, but in any case, I am closing this ticket.

Thanks for providing this tool!

chestnutcone commented 2 years ago

Hi @BatmanAoD ,

What programs are these windows which raise themselves from?

I use latest Windows (on Windows 11 Insider builds now, build 22000.160) as well as 21H1 (build 19043.1165) and I do not experience that behavior. I can, for example, mouse over Notepad when it is mostly covered by Firefox and it will receive focus without raising itself.

However, as noted in the Notes section of the website, MDI (Multiple Document Interface) applications (such as Visual Studio or things based on its shell like SSMS) will raise themselves when focused, which is quite annoying. But that is the application itself raising itself, so there is nothing that can be done about that. Those applications themselves would need to be changed to better support Windows’s focus follows mouse feature.

just FYI for future, if someone also had the same issue with Visual Studio self-raising, I found this advice from StackOverflow that solved it for me " A couple of days ago I found a solution for Visual Studio autoraising itself when you hover the mouse over a window: Options -> Environment -> Tabs and Windows -> uncheck both entries under 'Floating Windows'. ('floating tab wells stay on top' and 'floating tool windows stay on top') "

binki commented 2 years ago

@chestnutcone

just FYI for future, if someone also had the same issue with Visual Studio self-raising, I found this advice from StackOverflow that solved it for me " A couple of days ago I found a solution for Visual Studio autoraising itself when you hover the mouse over a window: Options -> Environment -> Tabs and Windows -> uncheck both entries under 'Floating Windows'. ('floating tab wells stay on top' and 'floating tool windows stay on top') "

Whoa, that does make a difference. Now Visual Studio only self-raises when it displays a tooltip (which happens quite often with C# code).

BatmanAoD commented 2 years ago

@chestnutcone Thanks for letting me know about that option! It looks like the behavior hasn't changed for me (VS still autoraises, even when I don't see any tooltips involved), but I'm glad it's helpful for others.

binki commented 2 years ago

Hmm, I don’t know. I thought it made an improvement, but I don’t think so anymore. Sometimes Visual Studio just gets lazy about raising itself unpredictably. I think that happened when I changed the setting originally, but the original behavior is back now. This just seems to be the usual “MDI apps love self-raising” thing.