XMonad.Prompt and XMonad.Actions.TreeSelect can freeze the UI

[rarsamx]

Problem Description

When invoking an XMonad.Prompt or an XMonad.Actions.TreeSelect, if the user clicks with the mouse in another application, XMonad stops responding to mouse or keyboard input when "clickJustFocuses = False"

Steps to reproduce:

1. Configure a prompt shell (The same can be achieved with any TreeSelect)
2. Trigger the binding to open the prompt
3. Click or double click in another application
4. At this point XMonad stops responding to mouse and keyboard input.

Workaround:

• Set the "clickJustFocuses = True"

Configuration File

import XMonad
import XMonad.Prompt
import XMonad.Prompt.Shell
import XMonad.Util.EZConfig

defXPConfig :: XPConfig
defXPConfig = def
      {
        font                = "xft:size=11"
      }

main = xmonad $ defaultConfig
    {
        clickJustFocuses    = False  -- If it is True the problem does not happen.
    }
    `additionalKeysP`
     [ 
      ("M-p"     , shellPrompt defXPConfig )     -- launch shell prompt
    ]

Checklist

• [ X] I've read CONTRIBUTING.md

• I tested my configuration with xmonad-testing (No, I don't know how to do this. I will try to follow the instructions in the repository, but I searched and couldn't find this reported as a bug.

[slotThe]

Theoretically, this is a duplicate of xmonad/xmonad/issues/116, but since that issue is in the wrong repo anyways I'll leave this open. There are some hacks temporary fixes posted in that issue, in case you don't want to use clickJustFocuses.

I was wondering why I had never run into this issue (despite not setting clickJustFocuses), even though I use all kinds of different prompts quite extensively; apparently, using XMonad.Actions.UpdatePointer.updatePointer also does something such that this issue doesn't occur.

I don't have a lot of X11 Fu, but I will try to look into this when I have the time (which is, frankly, not much at the moment); if anyone feels like they're up for a good treasure hunt, go ahead!

[rarsamx]

Thanks, I will go have a look.

It wasn't hard to try different things until I figured out a simple scenario to recreate. And given that there are workarounds, I just wanted to report it.

Thanks for the response

[slotThe]

The workarounds are certainly not ideal; so definitely thank you for reporting this!

So doing the simplest possible thing (literally just grabbing the pointer) actually seems to work:

diff --git a/XMonad/Prompt.hs b/XMonad/Prompt.hs
index 3beee72..ced30a5 100644
--- a/XMonad/Prompt.hs
+++ b/XMonad/Prompt.hs
@@ -596,8 +596,9 @@ runXP st = do
   let d = dpy st
       w = win st
   st' <- bracket
-    (grabKeyboard d w True grabModeAsync grabModeAsync currentTime)
-    (\_ -> ungrabKeyboard d currentTime)
+    (do grabPointer d w False buttonPressMask grabModeAsync grabModeAsync none none currentTime
+        grabKeyboard d w True grabModeAsync grabModeAsync currentTime)
+    (\_ -> ungrabPointer d currentTime >> ungrabKeyboard d currentTime)
     (\status ->
       (flip execStateT st $
         when (status == grabSuccess) $ do

(the buttonPressMask is just the first thing that came to mind; something else may fit better there)

Can you confirm?

I guess this would technically count as a regression as, e.g. with updatePointer, it's currrently possible to do things with the mouse in a window while the prompt is up. I'm not sure this matters much, but it may be worth looking for alternative solutions that don't have this problem

[rarsamx]

I'll read about out how to compile XMonad and apply this patch and will let you know.

Thanks

[rarsamx]

I tested the patch and it is working, I can see how the mouse hovering over other applications does not get a response from those applications as before. Also, I clicked everywhere and the system didn't freeze.

With the "faulty" implementation, if someone wanted to do something in another screen while the prompt was up, the action wouldn't work any way, so even if it is a regression, seems to be an explicit rule if it is documented that way "It's a feature" :)

I didn't test extensively, But for the sample xmonad.hs I had and my actual xmonad.hs it is working well.

An interesting thing is that XMonad.Actions.TreeSelect has the same problem. I had originally correlated the problem but I see that they don't depend on each other (No imports)

However, I saw the code and it calls the same "grabKeyboard" function in an almost identical way. Should I edit the title on this report and open another one for TreeSelect?

Thanks,

[slotThe]

On Tue, Jan 19 2021 22:34, Raul Suarez wrote: I tested the patch and it is working, I can see how the mouse hovering over other applications does not get a response from those applications as before. Also, I clicked everywhere and the system didn't freeze. [...] I didn't test extensively, But for the sample xmonad.hs I had and my actual xmonad.hs it is working well.

That's good to hear!

With the "faulty" implementation, if someone wanted to do something in another screen while the prompt was up, the action wouldn't work any way, so even if it is a regression, seems to be an explicit rule if it is documented that way "It's a feature" :)

Oh you're right—I tested this once again and I seem to be misremembering that selecting anything actually worked. In that case it's probably fine to include even this simple fix; I'll fix the `TreeSelect' implementation as well this weekend and prepare a pull request