Highrez

XMBC Version: 2.19.2
Windows Version: Windows 10 1909 Build 18363.900
Mouse Information (brand/model): Logitech K400plus keyboard
Relevant Computer Information (CPU, RAM etc): i5-8500 16gigs ram
Did the problem occur after an upgrade of XMBC? (If so, from what version?): No
Did the problem occur after a Windows update/upgrade? (If so, from what version?): No
How long have you used XMBC?: Years
What language and keyboard layout do you use in Windows?: US english

Clear description of the problem - try and include as much information as possible, including what button and mappings you are having problems with (if applicable).:

Love the software, but I've had this problem forever and I've finally cracked. I hold down the middle mouse button to scroll in firefox, and use the right mouse button to draw gestures. Unfortunately these buttons often fail to release until I press the button a second time. I have experimented with everything I can think of - chording, no chording, blocking, no blocking, mapping as simulated keystrokes (eg {MMB} ), on and on. After disabling XMBC the issue goes away. Holding down is not necessary, as even just clicking the buttons can cause them to get stuck.

Here's the big problem though, I use an autohotkey script to remap two keys on my keyboard, ESC and F1, to the middle and right mouse buttons respectively. I suspect this has something to do with it (Non-Client messages? Remap Simulated Output?)

I've tried a few different strategies for remapping in my AHK script, but it makes no difference. I wonder if an option can be added to loop a check to see if a button is actually being held down or not.

I recorded a log , but I don't see how to attach it. Perhaps it's because this is my first post...

Yes you need a few (5?) posts until you can atach files or send links (auto policy to reduce spam bots!). I will enable that for you shortly.

I suspect you could be right with your suspicions with AHK script introducing some confusion here causing buttons to get stuck (CTRL+ALT+DEL and then cancel should also fix stuck buttons (or keys)). XMBC uses SendInput (much like AHK does) and Windows itself does not like things being sent out of order. XMBC looks at the key state before sending the messages to make sure it does not send a key down message if it is already down (or up if it is already up) but I bet your AHK script isnt doing that.

My suspicion is as follows (I may be incorrect but its my first stab at figuring out whats going on without any evidence/trial and error this end! ):
If the key/button is down and you send another down message, or the key/button is UP and you send another UP message it seems to confuse Windows and things get stuck. This can also happens occasionally with XMBC alone when it looses track of state information (perhaps when other programs are manipulating states)
You may be able to modify your AHK script to help combat this - it would be interesting to see the script but maybe by checking the state of the key/button prior to sending anything and either delaying slightly or skipping the down message if already down (that may not have the desired effect).