-
Bug
-
Resolution: Fixed
-
P2
-
7
-
b134
-
generic
-
linux
-
Verified
Run a small attached test on a Gnome or other GTK-based window manager.
GTK FileDialog will appear. A separate thread will try to query and set location/bounds of the dialog. Apparently a window manager will ignore attempts to position the dialog: let's think it's OK for now. However when we ask about location and size of the dialog, it lies.
First, it does falsely report 0,0 (or whatever was set before show) as the location and then does report the location and size as if our unsuccessful attempt to change them has been successful.
It seems that the property in java was changed and retained without regard of success or failure of a setter.
GTK FileDialog will appear. A separate thread will try to query and set location/bounds of the dialog. Apparently a window manager will ignore attempts to position the dialog: let's think it's OK for now. However when we ask about location and size of the dialog, it lies.
First, it does falsely report 0,0 (or whatever was set before show) as the location and then does report the location and size as if our unsuccessful attempt to change them has been successful.
It seems that the property in java was changed and retained without regard of success or failure of a setter.
- relates to
-
JDK-7011513 GTK FileDialog modality issues
-
- Open
-
-
JDK-6179142 Should consider hierarchy changes for Print and File dialog windows peers
-
- Open
-