Linux: Dialog windows do not receive focus (after unfocusing and clicking on them)

[jakubt]

What steps will reproduce the problem?

1. Open josm. (main window opens)
2. Open Preferences. (Preferences window opens on top of main window)
3. Click on main window.
4. Clink on Preferences window.

What is the expected result?

The preferences window shall receive focus, namely the components of the window should react to mouse clicks etc.

What happens instead?

The window seems that it does not receive focus, once it loses it. It can be closed and boundaries and title bar react (so there is some basic focus after all), but no components within window react on clicks. Instead it seems as if it was "transparent" to clicks - if there is something clickable under the window (i.e. link in the main window) it gets the click event.

Please provide any additional information below. Attach a screenshot if possible.

• Strange thing is that this "transparecy" is only valid for mouse actions. It is still possible to navigate with keybord using Tab, Arrows etc, this is the only way to edit relations at this time for me.
• After closing the Preferences and reopening them again, the Preference window reacts normally until it loses focus.
• The same thing happens with relation editor and some other window.
• Myspecs are below - i use KDE 4.14 from debian repositories.
• The bug has been present for a long time and it is present on my other linux machines as well. I have a feeling that it used to work time to time, but now it seems to be buggy everytime I try. The bug makes relation editing very cumbersome.
• I tried to find a temporary solution by tweaking window manager on one of the computers, but it did not work either. The best thing I was able to achieve was to prevent the window from loosing the focus in step 3, but it is not very usable either, when I am editing complex relations, I need to be able to click on ways/nodes in main window to add them to relation for example.

Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2014-08-27 01:35:43
Last Changed Author: Don-vip
Revision: 7445
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2014-08-27 02:41:05 +0200 (Wed, 27 Aug 2014)
Last Changed Rev: 7445

Identification: JOSM/1.5 (7445 cs) Linux Debian GNU/Linux testing (jessie)
Memory Usage: 163 MB / 1331 MB (79 MB allocated, but free)
Java version: 1.7.0_65, Oracle Corporation, OpenJDK 64-Bit Server VM
Java package: openjdk-7-jre:amd64-7u65-2.5.1-4
VM arguments: [-Djava.net.useSystemProxies=true]

Plugins:
- FastDraw (30416)
- OpeningHoursEditor (30519)
- buildings_tools (30485)
- imagery_offset_db (30534)
- notes (v0.9.4)
- routes (30416)
- terracer (30416)
- turnlanes (30416)
- turnrestrictions (30454)
- utilsplugin2 (30460)

[Don-vip]

Ticket #9764 has been marked as a duplicate of this ticket.

[skyper]

typo

[Don-vip]

Ticket #10463 has been marked as a duplicate of this ticket.

[mueschel]

Just two things I tested:

If I restart the window manager kwin --replace the situation gets better temporarily - no errors for a while.
On the other hand, the problem seems not be related to kwin itself:
If I use openbox openbox --replace, the situation is usually even worse than when using kwin and windows behave much more erratically.

As I wrote in #10463 (without noticing this bug report), a direct work-around is to open a context menu in the main window - then the dialog window works as expected. Also, the bug appears with every detached window as well, e.g. the selection box.

[jakubt]

I can confirm that the annoying workaround mentioned in #10463 works, namely "right-click the main window to open a context menu, then click in the child window.". This should surely point developers in the right directions. Please ask if I can help anyhow in hunting down this bug, it makes more complex editing relations in KDE very unplesant if not impossible.

[jakubt]

Jan,

I have just discovered one think ... can you try it yourself? Namely: Go to Edit > Preferences > Display Settings > Look and Feel

and select GTK+ in Look and Feel combo box.

Does it help?

Just two things I tested:

If I restart the window manager kwin --replace the situation gets better temporarily - no errors for a while.
On the other hand, the problem seems not be related to kwin itself:
If I use openbox openbox --replace, the situation is usually even worse than when using kwin and windows behave much more erratically.

As I wrote in #10463 (without noticing this bug report), a direct work-around is to open a context menu in the main window - then the dialog window works as expected. Also, the bug appears with every detached window as well, e.g. the selection box.

[anonymous]

Hello jakubt,

since I also suffer from this bug, i tried your workaround in comment 10 and have to say that in GTK+ look an feel mode I can edit relations again. So the problem does not occur there.

[anonymous]

Replying to anonymous:

Hello jakubt,

since I also suffer from this bug, i tried your workaround in comment 10 and have to say that in GTK+ look an feel mode I can edit relations again. So the problem does not occur there.

Sorry, I was too quick with my post, the problem still persists in GTK+ Look and Feel :(

[mueschel]

As jakubt wrote, there is no difference when using the GTK+ style.
From time to time also the main window is not reacting on clicks any more. After pressing F10 and opening a menu, it again reacts for a short while. The problem appeared when switching to Java 7 - with Java 6 the problem never happened. At the time JOSM still run with Java 1.6 I tested this: Using the identical JOSM version, the problem happened when running Java 7, but does not happen with Java 6.

[jakubt]

Unfortunately I am confirming your observations. For a while it functioned well, but the mistake is back. It might have something to do with the fact that I use multiple monitors.

[mueschel]

Nope, the screen configuration does not make a difference. I do have a single screen.
It would be really nice if some developers could have a look on this nasty bug - editing relations is more or less impossible since half a year now.

[markus.heidelberg@…]

Screenshot of KDE keyboard layout settings: focus problem vanishes for "de" if it stands at the top.

[markus.heidelberg@…]

I suffered from the focus problem as well. This week accidentally I stumbled across this ticket and decided to finally investigate.

The first time I encountered this bug on 2014-08-01. From my OpenStreetMap edits, I assumed the regression should have been introduced sometime in July. I had the feeling that it worked before a KDE update and searched for some suspicious packages in the pacman install log. Here is what I got:

[2014-07-12 19:12] [PACMAN] upgraded jdk7-openjdk (7.u60_2.5.0-2 -> 7.u60_2.5.0-3)
[2014-07-22 11:32] [PACMAN] upgraded kdelibs (4.13.2-3 -> 4.13.3-1)
[2014-07-22 11:32] [PACMAN] upgraded jdk7-openjdk (7.u60_2.5.0-3 -> 7.u65_2.5.1-3)
[2014-07-31 19:52] [PACMAN] upgraded xorg-server (1.15.2-1 -> 1.16.0-6)

I tested some downgrades where I still had the old install package in the cache, but without success. Specifically this was xorg with dependencies.

A few days or weeks later I found out that there was no problem when using twm instead of a KDE session. And the problem also did not occur in KDE using another user account. So I thought it has to be some KDE configuration triggering this bug. I also tested different Java applications and each one except Eclipse had the same problem (Swing vs. SWT?). TV-Browser additionally showed another behaviour: the left mouse button on the main view normally opens the program info, but this did not work anymore, the context menu with the right mouse button still worked.

Thanks to this ticket, yesterday I started to dig in to find the cause for this problem. I started by replacing the complete ~/.kde4/share/config/ directory on the test account with my original content and this already triggered the bug. I bisected it down to the file ~/.kde4/share/config/kxkbrc as the culprit. There the keyboard settings from KDE System Settings are saved, directly accessible via command "kcmshell4 kcm_keyboard". Here my original content:

[Layout]
DisplayNames=,
LayoutList=us,de(nodeadkeys)
LayoutLoopCount=-1
Model=pc105
ResetOldOptions=false
ShowFlag=false
ShowLabel=true
ShowLayoutIndicator=false
ShowSingle=false
SwitchMode=Global
Use=true

I switched to the US layout via KDE system tray tool and the problem was gone. At first I thought there is some bad influence of the German keyboard layout, but I found out that the order of the layouts has impact on the bug. I swapped the order, resulting in the config file line below, and then I got the bug with "us", but it worked properly with "de":

LayoutList=de(nodeadkeys),us

Long story short:
As a workaround for this focus problem you have to move your keyboard layout up to the first position. For me it is "de", see ​screenshot.

After having found this bug in the KDE keyboard layout setting, I'm not really sure anymore if it occured with the KDE update from 4.13.2 to 4.13.3 in July 2014 or if I changed my layout configuration around this time.
@jakubt: What time frame did you mean with "The bug has been present for a long time" you wrote above on 2014-08-27?

Maybe a related KDE bug is that after switching the order, the layout is being switched as well.

Side note:
The bug in ticket #11230 I only found because I could not press "Cancel" due to the focus problem from this ticket.

[simgunz@…]

I had the same problem in MATLAB. Comment 16 solved the problem to me.
I would like to immensely thank the person who has did the debugging of this problem, it was affecting me since 4 months.
Great work!

[simgunz@…]

By the way, has this been reported to the KDE bug system?
I can do it otherwise.

[markus.heidelberg@…]

No, I haven't reported it yet. Feel free to do it, I'd appreciate it. Please also add a link to the JOSM bug report there and vice versa.
The bug probably sits in project kde-workspace, there kxkbrc is read and written. But since this is not selectable in the bugtracker, kdelibs may be appropriate alternatively.

[simgunz]

KDE bug report:
​https://bugs.kde.org/show_bug.cgi?id=345386

[Self-Perfection]

This bug is not specific to KDE, I've seen the same problem on two systems with XFCE.

[*Martin*]

The same problem on XFCE. Trich with the keyboard layout works it around.

[anonymous]

Same problem with MATLAB 2014b in Linux Mint 18 Cinnamon. Comment 16 works. Thanks!

[anonymous]

Same problem with Matlab2014b in Linux Mint 18 Cinnamon. Comment 16 solved the problem. Thanks!!!

[anonymous]

Same problem with Matlab 2016a in Ubuntu 16.04 LTS. Comment 16 works, truly weird behaviour.

[alexeytitov@…]

Thanks a lot for the 16 comment!

[luca.tagliacozzo@…]

Same problem with Matlab R2017a in Kubuntu 16.04 LTS and XFCE

[anonymous]

Confirmed with Matlab R2017a in Ubuntu 18.04 LTS and KDE5