Modify

Opened 10 years ago

Closed 7 years ago

Last modified 5 years ago

#10430 closed defect (othersoftware)

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

Reported by: jakubt Owned by: team
Priority: major Milestone:
Component: Core Version:
Keywords: template_report linux java7 focus keyboard layout Cc: mueschel

Description

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)

Attachments (1)

keyboard-layout-setting.png (81.0 KB ) - added by markus.heidelberg@… 9 years ago.
Screenshot of KDE keyboard layout settings: focus problem vanishes for "de" if it stands at the top.

Download all attachments as: .zip

Change History (31)

comment:1 by Don-vip, 10 years ago

Keywords: linux kde added

comment:2 by Don-vip, 10 years ago

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

comment:3 by skyper, 10 years ago

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

typo

comment:4 by Don-vip, 10 years ago

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

comment:5 by Don-vip, 10 years ago

Cc: mueschel added

comment:6 by Don-vip, 10 years ago

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

comment:7 by mueschel, 10 years ago

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.

comment:8 by jakubt, 9 years ago

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.

comment:9 by jakubt, 9 years ago

Priority: normalmajor

in reply to:  7 comment:10 by jakubt, 9 years ago

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.

comment:11 by anonymous, 9 years ago

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.

in reply to:  11 comment:12 by anonymous, 9 years ago

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 :(

comment:13 by mueschel, 9 years ago

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.

comment:14 by jakubt, 9 years ago

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.

comment:15 by mueschel, 9 years ago

Keywords: java7 added; kde removed

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.

by markus.heidelberg@…, 9 years ago

Attachment: keyboard-layout-setting.png added

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

comment:16 by markus.heidelberg@…, 9 years ago

Keywords: kde added

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.

comment:17 by simgunz@…, 9 years ago

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!

comment:18 by simgunz@…, 9 years ago

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

comment:19 by markus.heidelberg@…, 9 years ago

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.

comment:21 by Self-Perfection, 9 years ago

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

comment:22 by Self-Perfection, 9 years ago

Keywords: kde removed

comment:23 by *Martin*, 8 years ago

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

comment:24 by anonymous, 7 years ago

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

comment:25 by anonymous, 7 years ago

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

comment:26 by anonymous, 7 years ago

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

comment:27 by alexeytitov@…, 7 years ago

Thanks a lot for the 16 comment!

comment:28 by Don-vip, 7 years ago

Keywords: focus keyboard layout added
Resolution: othersoftware
Status: newclosed

comment:29 by luca.tagliacozzo@…, 7 years ago

Same problem with Matlab R2017a in Kubuntu 16.04 LTS and XFCE

comment:30 by anonymous, 5 years ago

Confirmed with Matlab R2017a in Ubuntu 18.04 LTS and KDE5

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.