Regression: User's Input Not Suppressed, Windows Lose Focus

[davidhfo]

Hello, Philip. Thank you so much for your work on this program! I was happy to find it, and it has been quite useful to me.

Been using the 0.5.1 release for a while and liking it.

Saw your major new release, and am trying it out. Looking forward to trying out many of the new features added.

Two issues have cropped up that were not there in 0.5.1 for me. But they are in the last two releases: 0.6.0/0.5.2 and 1.0.

1. Input command: The user's input is no longer suppressed.
2. Windows lose focus after every hotkey, while the window itself remains active.

So, for example, when running the script

`;::
Input, trigger, I, {Space}
if trigger = btw
{
    Sleep, 60
    Send, by the way
}
return

When I type ;btw, the result is:

• 0.5.1: by the way, as expected.

• 1.0:

  • The first time it is entered, I get the expected result, by the way.
  • Upon hitting the ending character (Space), the window immediately loses focus, while remaining active (by this I mean if I type whatever, it still appears in the app).
  • Subsequent times the hotkey is used, the result is btw by the way (the same non-suppression would happen with other input hotkeys).
  • This is the case with Kate, LibreOffice Writer, and Chrome, for example.
  • Curiously, it does not happen in Firefox. In Firefox it is fine every time, and the window does not lose focus, either.

Regarding the window losing focus, it also throws off the Alt+Tab order. So if I have three apps open: Chrome, Firefox, and Kate. And Chrome is active, Firefox last used, and Kate used before that. After using the hotkey while in Chrome, pressing Alt+Tab goes to Kate instead of Firefox.

And the window losing focus is for any hotkey, not just ones having to do with the Input command.

• 0.6.0: In the event it is useful, I'll also mention what happens in 0.6.0/0.5.2:
  • First time: y the way. Subsequent times: ;btw by the way.
  • Window loses focus.
  • Kate, LibreOffice Writer, Chrome have the issue. Firefox it is consistently y the way.

These issues were not present in 0.5.1.

I am using Solus Linux 4.4, Plasma edition.

Note: In 0.5.1 I got into a habit of using a Sleep, 60 prior to any Inputs I use, so that if the ending character or input is contained in the output, it doesn't cause any problems. I tried without it in 1.0, but the first instance of the ending character in the output text was still removed (so, e.g., by the way becomes bythe way).

[phil294]

Hi @davidhfo,

thanks for this detailed report, it was very helpful. The main bug you experienced happened only on Solus Linux, but I could solve them in a VM. Would be great if you could test out version 1.0.1.

bythe way

This is now also solved, so you don't need to add the Sleep, 60 anymore. Alternatively, you could have done Send, {Space Up}by the way but it doesn't matter anymore now anyway. In the previous update, I fixed that already, but only for Hotstrings - not for Inputs, so it's good you noticed it. But if you don't mind me asking, why are you not using Hotstrings directly?

::;btw::by the way

um yeah ok so this doesn't work apparently, I just tested it out. The semicolon at the start breaks things. Was that the reason?

Alt+Tab order

Is this fixed now?

[davidhfo]

Hey, @phil294. Thank you for looking into this!

The Input command is now suppressing user input as expected. :)

why are you not using Hotstrings directly? … The semicolon at the start breaks things. Was that the reason?

I can't remember if I saw that before (semi-colon at beginning of hotstring not working). I use the semi-colon as a starting point for a few things, some of which do essentially the same thing as a hotstring, but others will change variables and then send confirmatory message boxes. Since I wanted to do both using the same starting key, I landed on using Input with various sections under it, depending on what I wanted to do. But more often than that, I use a couple of modifier/mouse hotkeys that then wait for user input to determine, e.g., how many of an action to take, but the user input was not suppressed in 1.0 so it was throwing the result off. In any case, it's fixed now. So, thanks again!

For me, windows are still losing focus, and Alt + Tab order is not fixed.

To demonstrate, I create a script with the following lines, with a couple videos to show it being used:

:*:btw::by the way

^LButton::
Send, {LCtrl Up} ; (see note at end)
Send, into the valley
return

1::
Input, trigger, V, {Space}
if trigger = ooh
    Send, over one hill
return

2::
Input, trigger, , {Space}
if trigger = oth
    Send, over two hills
return

1. Pressing Alt + Tab shows prior window is Calc. Press it again, it switches back to Kate.

2. Typing btw (hotstring), window does not lose focus.

3. Holding down Ctrl, as soon as mouse is clicked to fire the ^LButton hotkey, the window loses focus.

   • Window Spy also shows the window / title of Kate is no longer active.
   • However, typing still appears in Kate.
   • Alt + Tab then goes to Dolphin instead of Calc.

4. Pressing 1 to trigger waiting for input, results are much the same as previous. Window loses focus right away. Type ooh Space. Pressing Alt + Tab now goes back to Calc again, as the order has been changed (back).

https://github.com/phil294/AHK_X11/assets/6278065/9a811cb2-715c-4dcf-8426-0ff49d30ce9a

5. A little different: if user input is not suppressed (standard, no options), upon pressing 2, focus will flash away and then back immediately (blink and you'll miss it). Type oth. As soon as Space is pressed, then the window loses focus.

https://github.com/phil294/AHK_X11/assets/6278065/6c2e5377-5ed4-4ec5-a3af-71481d158807

Note: Seeing your comment that

Alternatively, you could have done Send, {Space Up}by the way

reminded me that when I found out about an earlier release and was setting up several scripts with modifiers, I ended up creating a subroutine to just Sleep a few ms and then Send, {Up} on all modifiers I might have used. Then I just set any hotkeys with modifiers to jump to that subroutine right at the beginning. The only real downside to it (for my own present use) is that I cannot press two hotkeys with the same modifier in quick succession without lifting up and then pressing down the modifier again. But I got used to it. And I noticed recently that I don't need the Sleep, so now it just looks like:

HotkeyFix:
Send, {LCtrl Up}{LAlt Up}{LWin Up}{Shift Up}
return

With the Input command now working as expected, I've been trying out all of my hotkeys on 1.0.1, and noticed a couple other things I'll report.

[davidhfo]

Oh, also not affected: hotkeys that send message boxes, when ok is clicked, do properly return the focus to the prior window.

[phil294]

Please add #XGrabRoot anywhere in your script and try again

[phil294]

xgrabroot reverts the logic back to how it was in v0.5.1. I didn't make it the default because it comes with the downside of sometimes closing popup/context windows on hotkey key press.

I'm not quite sure on which kinds of systems the problems you were facing can appear, but so far only Solus Linux appeared to have that for me. Other KDEs (tested with x11docker) didn't. So I hope you're fine with using this directive, at least as long as it only affects very few users. Would be great to auto-detect somehow though... who knows what it depends on.

So thanks once again for your detailed reports. Everything should work now, including the alt-tab problem.

I use the semi-colon as a starting point for a few things [...]

ok makes sense

Send, {LCtrl Up}{LAlt Up}{LWin Up}{Shift Up}

this might still be necessary sometimes because of #54. Not sure yet when I'll fix that. But when you set SetKeyDelay, -1 it should mostly not be a problem at all anymore.

[davidhfo]

Using #XGrabRoot works perfectly! Thank you!