#7944 closed defect (othersoftware)
Menus not working properly
Reported by: | Denzil | Owned by: | team |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Core | Version: | tested |
Keywords: | Cc: |
Description (last modified by )
Using version 5356 on Linux Mint 13. The menus and buttons do not respond to the mouse correctly. The mouse needs to be clicked away from the button in order for it to respond, and the menus do not stay opened, making it almost impossible to select menu items.
Attachments (0)
Change History (14)
comment:1 by , 13 years ago
Description: | modified (diff) |
---|
comment:2 by , 13 years ago
comment:3 by , 13 years ago
Same every time. The effect of the cursor is offset from the actual cursor position. Example: I click on Images, the menu appears, but only for as long as I hold the mouse button. If I move the cursor straight down, the Images menu disappears and the Tools menu opens. If I click on Imagery, hold the mouse button, then move across to Audio, then move down, I get the Imagery menu items, but the highlighted option is one row above the cursor position.
Tested on another PC also running LM13 - works fine, so is specific to this PC.
comment:4 by , 13 years ago
Resolution: | → othersoftware |
---|---|
Status: | new → closed |
Hm, sounds like a Java or OS bug, not much we can do about. Installing Oracle Java may be worth a shot.
comment:5 by , 13 years ago
I know this effect from using Josm under linux displayed with Xming on a windows system. Not a josm issue.
comment:6 by , 12 years ago
I had the same problem (also with Mint) and found a solution. Open the .josm/preferences.xml and delete the two tags containing
gui.geometry
gui.maximized
After a restart it should work fine again. Deleting these tags resets the values for the window size. Somehow josm thinks that the window has a different size (once you close it in a non maximized state) which causes the mouse offset.
If the problem was already there when using josm for the first time, maybe it helps to adjust the gui.geometry to your screen geometry.
comment:7 by , 12 years ago
Resolution: | othersoftware |
---|---|
Status: | closed → reopened |
I suppose that Josm save internally the position (rectangle) of the application. When the application is closed, this rectangle is saved to gui.geometry.
IMHO seems that when Josm go to maximized state, the rectangle is not updated and the application use the last rectangle in non maximized state. If your normal state is with the window at X=0, Y=0 you don't see any problem between maximized or normal state. But if you have the window at X= 200, Y=200 (far from the upper left corner of your screen) in normal mode and put the application to maximized state, the problem appear.
Step to reproduce:
- Open Josm in NORMAL state
- Move the upper left corner of the window in the middle of screen
- Mouse is working correctly
- Put the window in MAXIMIZED state
- Mouse is NOT working correctly
Step that don't reproduce the problem:
- Open Josm in NORMAL state
- Move the upper left corner of the window in the upper left corner of the screen
- Mouse is working correctly
- Put the window in MAXIMIZED state
- Mouse is working correctly because the menu has the same position as before
comment:9 by , 12 years ago
Me too on Fedora:
$ josm --version
JOSM/1.5 (6115 SVN it) Linux Fedora 19 (Schrödinger’s Cat)
$ java -version
java version "1.7.0_40"
OpenJDK Runtime Environment (fedora-2.4.2.4.fc19-x86_64 u40-b60)
OpenJDK 64-Bit Server VM (build 24.0-b56, mixed mode)
comment:10 by , 12 years ago
Summary: | Menus not working properly → In Maximized state menus not working properly |
---|
Still I don't see how JOSM should be at fault here? We only store the windows position to remember position and call Java UI functions. We don't use this for click calculations or whatever other stuff. Java handles the menus itself.
comment:11 by , 12 years ago
Resolution: | → othersoftware |
---|---|
Status: | reopened → closed |
Summary: | In Maximized state menus not working properly → Menus not working properly |
After some investigation the problem is clearly due to Java. Java try to detect the Window Manager name and use the WM name under a switch statement without a default case. Obviously newer names, like "Marco" in LinuxMint Mate, don't work as expected. This issue is fixed in OpenJdk-8.
https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/777425
http://hg.openjdk.java.net/jdk8/awt/jdk/file/dcdf8cd4b09e/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java (line 753)
comment:12 by , 12 years ago
Thanks for finding the bug ! I have added JOSM and myself as impacted projects/users to increase bug heat, that's the best we can do (I also invite all impacted people to do the same if they want the bug fixed at least in Ubuntu implementation)
Could you start JOSM repeatedly and see if the bug remains the same every time?
Also a more detailed explanation would be helpful, to better understand the problem.