Popup (code completion) window disappears

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start IntelliJ IDE (I tried phpstorm)
2. Do word completion ("IntelliSense") and find a long method 
signature/description in the popup
3. Completion popup window mostly disappears (see attached photo).

What is the expected output? What do you see instead?
That the window stays visible

What version of the product are you using? On what operating system?
$ xmonad --version
xmonad 0.11

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 13.04
Release:    13.04
Codename:   raring

Are you using an xmonad.hs? 
import XMonad
import XMonad.Hooks.SetWMName
import XMonad.Hooks.DynamicLog
import XMonad.Hooks.ICCCMFocus
import XMonad.Hooks.ManageHelpers
import XMonad.Hooks.EwmhDesktops

main = xmonad $ defaultConfig
    {
        modMask = mod4Mask,
        startupHook = setWMName "LG3D" >> takeTopFocus,
        manageHook = composeOne [
            transience,
            isFullscreen -?> doFullFloat
        ],
        logHook = setWMName "LG3D" >> takeTopFocus
    }

Log of xmonad --recompile is empty.

Original issue reported on code.google.com by j...@jupiter.dk on 5 Nov 2013 at 9:13

Attachments:

• phpstorm-xmonad.png

[GoogleCodeExporter]

I have similar issues as well. However mine is less severe as it only happens 
half of the time.

Original comment by lingna...@gmail.com on 5 Nov 2013 at 12:25

[GoogleCodeExporter]

The i3 wm does a better job and configuration is less of a nightmare (java 
programs just work - no stupid hacks or anything). This bug is a severe 
showstopper and I am not looking back after switching to i3.

Original comment by j...@jupiter.dk on 17 Jan 2014 at 10:23

[GoogleCodeExporter]

I've got this in my setup as well. It's really annoying.. you can sometimes 
work-around it by narrowing down the number of matches by typing part of the 
method name you're hunting for.

-> % xmonad --version
xmonad 0.11

-> % lsb_release -a
LSB Version:    1.4
Distributor ID: Arch
Description:    Arch Linux
Release:        rolling
Codename:       n/a

Original comment by epirea...@gmail.com on 20 Jan 2014 at 3:26

[GoogleCodeExporter]

Same problem for me, but only if I use oracle jdk7. With sun jdk6 on the other 
hand, it works flawlessly. Maybe this helps you tracking down the issue.

Original comment by carsten....@googlemail.com on 7 Feb 2014 at 9:06

[GoogleCodeExporter]

Same issue here. Probably results from focus acquired by small window with long 
completion string (does not happen on jdk6). Maybe diff between xprop for the 
small window on jdk6 and jdk7 can be useful (removed all ids).

Original comment by Jan.Palus on 6 Mar 2014 at 12:57

Attachments:

• xprop.diff

[GoogleCodeExporter]

Looking further at xprop difference on jdk7 between main completion popup 
(which does not take focus) and small complementary window for long completions 
(which does), the main differnece looks to be in:

WM_STATE(WM_STATE):
    window state: Normal

which is present for the later. Is anyone aware if windows with normal states 
are managed in a different way?

Original comment by Jan.Palus on 10 Mar 2014 at 1:27

[GoogleCodeExporter]

The window without WM_STATE is not ICCCM compliant, as WM_STATE is mandatory. I 
would not be surprised if xmonad catches an exception while trying to manage it 
because it doesn't have the window attributes that all windows are required to 
have.

Original comment by allber...@gmail.com on 10 Mar 2014 at 1:49

[GoogleCodeExporter]

So most probably it worked as expected for jdk6 as it was more broken then 
jdk7? Ironic :)

Looking at hints section:

  Window manager hints:
      Client accepts input or input focus: No
      Window type:
          Dialog
      Window state:
          Skip Taskbar

specifically "Client accepts input or input focus: No", does this mean such 
window should not receive focus? And if yes, does xmonad support this hint? 

Original comment by Jan.Palus on 10 Mar 2014 at 8:33

[GoogleCodeExporter]

Apparently input hint is of no importance here (especially that most jdk7 
windows have this flag set to false). What distinguishes problematic window 
from others is lack of WM_TAKE_FOCUS atom. Both params "input hint" and 
"WM_TAKE_FOCUS" seem to be evaluated in setFocusX function, but from my 
investigation none of the "whens" is applied there. Which function actually 
changes focus to new window? Should it consider WM_TAKE_FOCUS?

Original comment by Jan.Palus on 11 Mar 2014 at 1:57

[GoogleCodeExporter]

Yet another observation... the main completion window actually does not 
disappear, it just goes down below every other window. Probably because it is 
not managed by xmonad due to missing WM_STATE which might be in the end the 
root cause.

Original comment by Jan.Palus on 11 Mar 2014 at 3:09

[GoogleCodeExporter]

Nah, the problem with main completion window not being managed by xmonad is not 
lack of WM_STATE but rather lack of MapRequest event on its creation (only 
*Notify events are generated). If I replace handler for MapRequestEvent to 
process MapNotifyEvent it's kinda better -- main completion window stays up, 
but the additional small window never shows up as well as xmobar. No idea where 
to go from here - why MapRequest is not generated and how IntelliJ could 
possibly fix this...

Original comment by Jan.Palus on 11 Mar 2014 at 6:33

[GoogleCodeExporter]

These two comments on the Jetbrains bugtracker were a sufficient workaround for 
me.

http://youtrack.jetbrains.com/issue/IDEA-101072#comment=27-453372
http://youtrack.jetbrains.com/issue/IDEA-101072#comment=27-456320

Original comment by a...@mcelwee.me on 11 Mar 2014 at 7:49

[GoogleCodeExporter]

Interesting - I had a look at the Jetbrains issue tracker, and there's a 
work-around that seems to solve this for me (!):

http://youtrack.jetbrains.com/issue/IDEA-101072

Basically - start IDEA with -Dide.expansion.hints.enabled=false to avoid this 
behavior. There are also some comments that discusses an alternative way of 
solving the issue by tweaking the xmonad config.

Original comment by epirea...@gmail.com on 11 Mar 2014 at 7:50

[GoogleCodeExporter]

Jan.Palus: that means it's keeping one window around and hiding it by burying 
it. But the first time it shows up it should be mapped and therefore managed... 
Is it perhaps override_redirect?

Original comment by allber...@gmail.com on 11 Mar 2014 at 9:23

[GoogleCodeExporter]

So the first time it shows up, only 3 Notify events are generated: Create, 
Configure, Map, but during idea startup there are 3 MapRequests - one for 
splash screen I guees, second for main window, not sure if third might be for 
completion window which is not there yet. But indeed it has following 
properties set as reported by xwininfo:

  Override Redirect State: yes
  Override redirection?: Yes

Mentioned workaround (-Dide.expansion.hints.enabled=false) indeed keeps 
completion window up, at a small price of never showing the small window for 
long completions.

Original comment by Jan.Palus on 12 Mar 2014 at 7:39

[GoogleCodeExporter]

Just to add to previous comment - debug stack hook does not ever show window 
corresponding to completion window.

I also managed to minimize MapRequests during sturtup to 2 by closing any panel 
that might have spawned additional window, so it really seems completion window 
does not generate MapRequest.

Original comment by Jan.Palus on 12 Mar 2014 at 10:22

[GoogleCodeExporter]

It won't; override-redirect means the window manager has no control over the 
window, so ConfigureRequest and MapRequest will not be generated by the X 
server and we find out about it at MapNotify (at which point it is too late to 
manage it, by design) and cannot put it in the StackSet. It also means the 
application must manage the window itself.

Original comment by allber...@gmail.com on 13 Mar 2014 at 2:15

[GoogleCodeExporter]

Thanks, so actually the most convenient solution (at least that would work for 
sure), would be on idea side to preserve same window properties (override 
redirect mainly) for the small window with long completion. This way it would 
not be managed by xmonad and hence not result in stack refresh.

Original comment by Jan.Palus on 13 Mar 2014 at 10:01