Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intellij dialog windows close immediately #2204

Closed
0xR opened this Issue Feb 26, 2018 · 23 comments

Comments

Projects
None yet
@0xR
Copy link

0xR commented Feb 26, 2018

Output of awesome --version:

awesome v4.2 (Human after all)
 • Compiled against Lua 5.3.4 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.5
 • LGI version: 0.9.2

How to reproduce the issue:

  1. Install intellij
  2. Use the find file dialog (ctrl + shift + n)

Actual result:
Focus gets lost and the dialog window closes. Whether this happens in non deterministic.

Expected result:
Find file dialog opens and gets focus and stays open.

Related issues
#889
https://youtrack.jetbrains.com/issue/IDEA-155759
#255

Description
I reopened this since it was supposedly fixed. I'm still getting it.
Using the default rc.lua helped for a few minutes. But then it behaved the same as always.

@0xR 0xR changed the title Can't use intellij popups Intellij popups close immediately Feb 26, 2018

@0xR 0xR changed the title Intellij popups close immediately Intellij dialog windows close immediately Feb 26, 2018

@psychon

This comment has been minimized.

Copy link
Member

psychon commented Feb 26, 2018

TL;DR: Cannot reproduce.

I downloaded ideaIC-2017.3.4.tar.gz and ran it (idea-IC-173.4548.28/bin/idea.sh). Then I had to click through some dialogs to get this thing to actually start.... Okay, so I assume I have to create a new project, which means more dialogs to click through. Finally something that looks like the main window opens. I press ctrl+shift+n.
An "Enter file name" dialog comes up and disappears as soon as I switch the focus away.

foo

Edit: Oh and yes, I tried this a couple of times.

@0xR

This comment has been minimized.

Copy link
Author

0xR commented Feb 27, 2018

I recorded a screencapture. As you can see I'm having a really hard time opening the find file dialog. At first it didn't work at all, then I switched screens and after a couple of tries it worked again.

@Elv13

This comment has been minimized.

Copy link
Member

Elv13 commented Feb 27, 2018

Some potential tips (untested):

  1. Disable the ability of clients to move themselves:

    client.disconnect_signal("request::geometry", awful.ewmh.client_geometry_requests)

  2. Disable the focus follow mouse (comment those lines in rc.lua):

--client.connect_signal("mouse::enter", function(c)
--    if awful.layout.get(c.screen) ~= awful.layout.suit.magnifier
--        and awful.client.focus.filter(c) then
--        client.focus = c
--    end
--end)

If #1 works, you need to wrap the default handler in a custom one. If #2 works, you need to create a focus filter (see awful.ewmh documentation).

@0xR

This comment has been minimized.

Copy link
Author

0xR commented Feb 28, 2018

I tried both 1 and 2. It doesn't seem to help. Sometimes I think it works, but it is nondeterministic and will return the original broken behavior after a couple of minutes.

@pcaneill

This comment has been minimized.

Copy link

pcaneill commented Mar 9, 2018

I have been having the same issue for 3 years, on several distributions (debian, ubuntu, fedora), and several versions of awesome.

To add a little more information:

  • Sometimes the windows open and close itself directly, it appears to be the same behavior 0xR is having.
  • Sometimes the windows close while I am typing, regiving the focus to the main windows
@psychon

This comment has been minimized.

Copy link
Member

psychon commented Mar 9, 2018

Sometimes the windows close while I am typing, regiving the focus to the main windows

What the heck? But... at this point awesome does not do anything at all? (Unless you press key combinations intercepted by awesome) And if awesome would do something, it would do so deterministically, i.e. without racing with IntelliJ on anything (GrabKey means that only we get some key event and then we could use AllowEvent to also have IntelliJ see the keyboard event, if we want).

@ghost

This comment has been minimized.

Copy link

ghost commented Mar 15, 2018

Go to Settings > Appearance & Behavior > Appearance: and check "Automatically position mouse curson on default button". This solves the issue for me.
The problem is that awesome retains the focus in the mouse pointer and if you have activated the option "Hide navigation popups on focus loss" in IntelliJ, the popup disappears when awesome wm focuses the pointer in the main window.
Can be solved unchecking the "Hide navigation popups on focus loss" option.

@0xR

This comment has been minimized.

Copy link
Author

0xR commented Mar 15, 2018

Although the solution of @CaimStarks looked promising it didn't work. My mouse is moved when when I open a dialog and the dialog won't close when I focus the Intellij main window. But I still can't get dialogs to open reliably.

Note that dialogs still close when Intellij loses focus in its entirety. So that is probably what is still causing my dialogs to close immediately.

@veloc1

This comment has been minimized.

Copy link

veloc1 commented Mar 15, 2018

Have the same issue. Looks like it can be partially fixed with
{ rule_any = { name = { "win.*", }, }, properties = {focusable = false, ontop = true} }

But there is the other problem: when I click on popup, popup closes and nothing happens. Anyone get this issue?

@joekiller

This comment has been minimized.

Copy link

joekiller commented Mar 27, 2018

@veloc1 I have the same issue where the window will pop open and I can type in it but as soon as I click, it closes and nothing happens.

If I use my arrow keys and hit enter, then the dialog works.

Edit more info. When I run xprop -spy and click on the floating window (like pressing CTRL+Shift+A) I get:

_NET_WM_DESKTOP(CARDINAL) = 9
awful.client.property.floating(CARDINAL) = 1
_NET_FRAME_EXTENTS(CARDINAL) = 1, 1, 1, 1
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG
_NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_TASKBAR
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: False
		window id # of group leader: 0x2801153
WM_TRANSIENT_FOR(WINDOW): window id # 0x2801153
_NET_WM_PID(CARDINAL) = 21878
WM_CLIENT_MACHINE(STRING) = "joe-3510"
WM_PROTOCOLS(ATOM): protocols  WM_TAKE_FOCUS
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x0, 0x0, 0x0, 0x0
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified location: 411, 787
		program specified size: 964 by 252
		window gravity: NorthWest
WM_CLASS(STRING) = "sun-awt-X11-XWindowPeer", "jetbrains-idea"
WM_CLIENT_LEADER(WINDOW): window id # 0x2800008
_NET_WM_NAME(UTF8_STRING) = "win106"
WM_NAME(STRING) = "win106"

Then when I click the window again the properties spit out:

WM_NAME(STRING) = "win106"
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: False
		window id # of group leader: 0x2801153
@joekiller

This comment has been minimized.

Copy link

joekiller commented Mar 27, 2018

@veloc1 to fix the popup click close problem I did the following:

buttons = clientbuttons where clientbuttons was defined as:

clientbuttons = gears.table.join(
    awful.button({ }, 1, function (c) client.focus = c; c:raise() end),
    awful.button({ modkey }, 1, awful.mouse.client.move),
    awful.button({ modkey }, 3, awful.mouse.client.resize))

The raise is what killed it. so just comment that out.

@psychon

This comment has been minimized.

Copy link
Member

psychon commented Mar 28, 2018

...why? Why would anyone write code that says "if you raise this window, I'll just close it".

@joekiller

This comment has been minimized.

Copy link

joekiller commented Mar 28, 2018

Doesn't the code say, if you click on the client, raise it to the top and focus? Perhaps new intellij bug?

@psychon

This comment has been minimized.

Copy link
Member

psychon commented Mar 28, 2018

Well, yes, but I meant intellij. I briefly tried to find the relevant source code for this, found something on GitHub, but didn't find the right search query to identify the place where this popup is implemented.

@trb

This comment has been minimized.

Copy link

trb commented Apr 2, 2018

A while ago I created this rule set to handle Intellij popup windows:

{
  rule = {
    class = "jetbrains-idea",
    instance = "sun-awt-X11-XDialogPeer"
  }, 
  properties = {
    floating = true,
    focus = true
  }
}

but in the recent update they changed the instance name for those popup windows to sun-awt-X11-XWindowPeer, so I use this now:

{
  rule = {
    class = "jetbrains-idea",
    instance = "sun-awt-X11-XWindowPeer"
  }, 
  properties = {
    floating = true,
    focus = true
  }
}

That resolved the popup jumping around for me. Running xprop -spy for popup windows can be annoying, I run sleep 10 ; xprop -spy in a terminal, then trigger the popup window and wait until xprop starts. That way I get around issues with the mouse moving.

@brmiller

This comment has been minimized.

Copy link

brmiller commented Apr 9, 2018

This annoying behavior started plaguing me with IntelliJ 2018.1 a couple weeks ago. Happy to report that @veloc1 's solution above fixed it for me.

While I originally thought @veloc1's solution was working, it repositioned IntelliJ's floating dialogs in the upper-left of the active screen, meaning, multi-dialog menu items like | Go to Implementation | means that the sub-menus were on top of each other in the upper-left making it impossible to actually use them.

I've reverted this and am using @pszynk 's rules below for a few days and it seems to be working.

Debian 9, awesome 4.0-1 from standard debian archives

@pszynk

This comment has been minimized.

Copy link

pszynk commented Apr 10, 2018

Same problems with PyCharm 2018.1 and Idea 2018.1. Popups are problematic. As @p-himik in #2233 said, changing Java SDK version to OpenJDK 1.8 helps, but JetBrains products look better using their dedicated SDK (esp. fonts). Changing allow.dialog.based.popups on Intellij SDK doesn't do much for me. What seems to solve all my issues are merged solutions of @trb @veloc1 and @joekiller

{ rule = {
    class = "jetbrains-.*",
    instance = "sun-awt-X11-XWindowPeer"
    name = "win.*"
},
  properties = {
    floating = true,
    focus = true,
    focusable = false,
    ontop = true,
    placement = awful.placement.restore,
    buttons = {}
 }
},
@jupf

This comment has been minimized.

Copy link

jupf commented Apr 17, 2018

The merged solution from @pszynk is only working for me if I leave out the focus = true,

But then it works perfectly for me. Thank you all for investigating!

@Grandmother

This comment has been minimized.

Copy link

Grandmother commented Apr 18, 2018

Does everyone knows what is the root of this problem? May be awesome acts not so good if there is so much problems with Java applications?

@psychon, may be @pszynk's configuration should be hardcoded as a default behaviour?

And one more question. Can we write simple test application on java that would emulate actions we all have problems with and test if awesome acts properly?

@psychon

This comment has been minimized.

Copy link
Member

psychon commented Apr 18, 2018

May be awesome acts not so good if there is so much problems with Java applications?

All the problems that I investigated so far are actually Java's fault. There are standards (ICCCM, EWMH) that dictates how X11 works. Java does not care.

For example, in ICCCM, there is the following sentence:

Clients that are concerned with keeping track of the absolute position of a top-level window should [...]

Then there is Java which actually considers the required behaviour as a bug in KWin in some comment in the source code and does the right thing only if it detects KWin. Which means that KWin gets away with following the spec and all other WMs have to work around Java's brokeness (awesome does so, too, grep for Java in the source code).

Or another example: The famous "Java only shows gray windows"-bug. This is Java actively ignoring all(?) events on a window until it receives a ReparentNotify event. Which means they intentionally break on non-reparenting WMs, is totally nuts, and not allowed by any of the standards.

So, really, do not simply blame awesome for problems with Java. I actually investigated some of these problems and dug into Java's source code and figured some things out. I even remember bug reports to Java that explained their brokeness, but were simply ignored for years (sorry, I don't remember the details and cannot provide a link).

@psychon, may be @pszynk's configuration should be hardcoded as a default behaviour?

Forcing floating = true on windows is not something that everyone might like. focus = true does not actually do anything, I think (since it is the default). focusable = false might be the key here since it prevents the window from actually getting focused. However, then I'd wonder why this actually works anywhere else. Also, IntelliJ could just mark its windows unfocusable by itself. ontop = true is something that can be done in IntelliJ if they need it (no idea if Java exposes this, but at least from an X11 point of view this is possible). The placement does not actually do anything?!? How can you restore an old placement when a window appears newly...? If the problem here is that IntelliJ does not want the WM to move its window, then (a) it is reacting quite badly to the window being moved and (b) this means it is incompatible with every tiling WM. Oh and buttons = {}... why? Why would this not be necessary on other WMs?

And one more question. Can we write simple test application on java that would emulate actions we all have problems with and test if awesome acts properly?

Feel free to do that. It would actually be extremely helpful. I am prepared to debug any such problems that I can reproduce and tell you exactly what Java is doing wrong (but it might take some time).

@Grandmother

This comment has been minimized.

Copy link

Grandmother commented Apr 18, 2018

@psychon, thank you for reply. I know, that this problems are because of Java bugs. But I didn't know that Java bugs are already workarounded in WM so I asked my questions. Just because this configuration tricks looks like a rain dance and the most strange thing, that it works.

So if this tricks needed just for Jetbrains's products, we can just continue this discussion with them. And the test application would of course help with this issue. I don't know if I can write it. If I would, you would know first.

@aligator

This comment has been minimized.

Copy link

aligator commented Apr 21, 2018

I use now this rules:

clientbuttons_jetbrains = gears.table.join(
    awful.button({ modkey }, 1, awful.mouse.client.move),
    awful.button({ modkey }, 3, awful.mouse.client.resize)
)

...

awful.rules.rules = {
        ...
	{
            rule = {
                class = "jetbrains-.*",
            }, properties = { focus = true, buttons = clientbuttons_jetbrains }
        },
        {
            rule = {
                class = "jetbrains-.*",
                name = "win.*"
            }, properties = { titlebars_enabled = false, focusable = false, focus = true, floating = true, placement = awful.placement.restore }
        },
        ...
}

elwin1234 added a commit to elwin1234/awesome-copycats that referenced this issue May 4, 2018

Tuurlijk added a commit to Tuurlijk/dotfiles that referenced this issue May 8, 2018

@joekiller

This comment has been minimized.

Copy link

joekiller commented Jun 5, 2018

I checked in and it appears Intellij fixed this (https://youtrack.jetbrains.com/issue/IDEA-155759). I reverted my work around and it is all good!

This issue can likely be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.