Unity: wrong window dimensions / location in Java applications

[bastik]

In Java applications, the functions to set and get window dimensions and position do not work as expected. This problem is only observed in Unity but not gnome, Win., etc.

Details:

* Call setSize(200, 200) and setLocation(300,400) for a JDialog object.

* If you call getSize() and getLocation() directly after making the JDialog visible, the result will be (200,200) and (300,400). Calling getSize() and getLocation() again, a split second later, the result is now (200,200) and (301,428). In both cases, the values are wrong, the size and location is actually (202,229) and (300,400) as shown by a screen capture.

Consequences:

* If the dialog is designed to reach to the bottom of the screen, the lower end will be cut off about 30 pixel, so the window needs to be moved by the user each time to see the lower button row (e.g. settings dialog in netbeans on medium resolution screen).

* In applications that save and restore window position and size, the window will move down 28 pixel each time it is opened an closed (e.g. JOSM, preference dialog).

Expected behavior:

* The result of getLocation() should be constant for one window unless the user moves the window

* setSize(dx,dy) should not set the size of the content pane, but the size of the entire window, including window decorations

* be consistent for all Window objects, e.g. in the attached sample, the JFrame works correctly, but the JDialog shows the described bug

Output of the sample code (press button "click", then press button "click2"):

dlg.getLocationOnScreen()=java.awt.Point[x=300,y=400]
dlg.getLocationOnScreen()=java.awt.Point[x=301,y=428]

Note: Both getLocation() and getLocationOnScreen() return the same values.

Observed for the following Java versions:

java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.5) (6b24-1.11.5-0ubuntu1~12.10.1)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)

and

java version "1.7.0_09"
OpenJDK Runtime Environment (IcedTea7 2.3.4) (7u9-2.3.4-0ubuntu1.12.10.1)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

Ubuntu 12.10

unity-6.12.0-0ubuntu0.2

update: same behavior in gnome classic with compiz running

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1110138/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[bastik (bstk)]

select package

[Sam Spilsbury (smspillaz)]

Confirmed, thanks. I'll have a look at this one later today

[Sam Spilsbury (smspillaz)]

OK, I've uploaded a branch with the fix in tact. Unfortunately, that part of the code is not straightforward to get under test, and we can't do an integration test either because decor requires opengl.

I note here that AWT's behaviour is probably not 100% reliable - unless it waited around for an updated _NET_FRAME_EXTENTS, in which case, their behaviour was fine and the bug was ours.

[bastik (bstk)]

Thanks Sam, compiz is great, I appreciate your work!

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:compiz at revision None, scheduled for release in compiz, milestone 0.9.9.2

[Launchpad Janitor (janitor)]

This bug was fixed in the package compiz - 1:0.9.9~daily13.02.26-0ubuntu1

---------------
compiz (1:0.9.9~daily13.02.26-0ubuntu1) raring; urgency=low

  [ Sam Spilsbury ]
  * debian/ccp_plugin.patch:
    - Added new option --no-auto-load-ccp to prevent the ccp
      plugin from autoloading. Useful for tests where having
      this behaviour just causes problems from unwanted side-effects
    - Also adjust test framework to pass the new option
    - Fix typo
  * debian/rules:
    - We already auto-load the ccp plugin, no need to add it to the
      default plugins.
  * debian/control:
    - Add xorg-gtest, xserver-xorg-dev, libxi-dev as build-deps
  * debian/ubuntu_config.patch:
    - Adjust EWMH test for new value

  [ Sam Spilsbury <email address hidden>, Brandon Schaefer ]
  * [2013/02/20] compiz/unity don't run, just loading cpp (LP: #1130679)

  [ Sam Spilsbury ]
  * Unity: wrong window dimensions / location in Java applications (LP:
    #1110138)
  * Add copytex to default/unity profiles (LP: #1130160)
  * Closing windows sometimes shows black areas using Nvidia 313.x
    drivers (LP: #1119608)
  * [2013/02/20] compiz/unity don't run, just loading cpp (LP: #1130679)
  * Run xorg-gtest tests in CI (LP: #1120009)

  [ MC Return ]
  * CCSM: No icons and text in main screen, submenus of the plugins work
    normally (LP: #1130941)

  [ Automatic PS uploader ]
  * Automatic snapshot from revision 3621
 -- Automatic PS uploader <email address hidden> Tue, 26 Feb 2013 04:02:36 +0000

[ViViD (vivnet)]

I am now having what appears to be the same issue as reported in this bug, after the resolution to it. I began to notice this yesterday (March 1) with the release of compiz=1:0.9.9~daily13.03.01-0ubuntu1.

I've attached a screenshot of the issue.

[Julian Taylor (jtaylor)]

confirmed the issue with jdownloader, reverting this patch only fixes the issue

[ViViD (vivnet)]

The issue in my post appears to have been resolved.

[Dmitriy Balakin (0x0000.ru)]

After applying this patch to Ubuntu 12.04 Compiz 0.9.7, there was a regression in the JFrame windows without decorations. Screenshot in attachment, the sample code here: http://www.java2s.com/Tutorial/Java/0240__Swing/SpecifyingWindowDecorations.htm

[Stephen M. Webb (bregma)]

Closing Compiz 0.9.9 task (0.9.9 series is obsolete)

[Sharcoux (darksharcoux)]

I also face the bug. I think that the discussion made at http://stackoverflow.com/questions/30836201/jframe-wrong-location-with-ubuntu-unity can help understand and track the bug. The issue is that the behaviour is random. See my edit to detect when it happens.

[Chris (chris-j-barwise)]

I see a similar problem in Java 8u66 on Ubuntu 14 LTS (just installed). When the JFrame is repeatedly launched (using setLocation) and saves location derived using either getLocation() or getLocationOnScreen() the JFrame wanders noticeably down the screen.

[Chris (chris-j-barwise)]

I should add I was using the 32-bit JRE.

[Chris (chris-j-barwise)]

Ran the code supplied for the original bug to confirm it is the same bug as the original and it is the same problem under Ubuntu 14.04 LTS with Java 8u66 32-bit JRE

[Misha (fomisha)]

I'm on Ubuntu 15.10
using
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)

When using some java applications (specifically Interactive Brokers TWS), about 10% of the time Ubuntu cannot figure out the size or the position of the window or which window is on top. So, you click on one window and miss or an action of another window (the one behind) is activated. This usually gets fixed by system reboot or

wetsid unity

I have not seen this behavior with any application other than TWS, which is a java application. I would be happy to provide more details.