JDK-4102292 : New AWT Frame w/o coordinates always pops up in upper left hand screen location.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version:
    solaris_2.6,1.1,1.1.5,1.1.6,1.2.0,1.2.2,1.3.0,1.4.0,1.4.1 solaris_2.6,1.1,1.1.5,1.1.6,1.2.0,1.2.2,1.3.0,1.4.0,1.4.1
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    generic,linux,solaris_2.5,solaris_2.5.1,solaris_2.6,solaris_9 generic,linux,solaris_2.5,solaris_2.5.1,solaris_2.6,solaris_9
  • CPU: generic,x86,sparc
  • Submitted: 1998-01-07
  • Updated: 2017-05-16
  • Resolved: 2003-08-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0 tigerFixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Description
Between JDK1.1.4 and JDK1.1.5 on the Solaris 2.5.1 platform the behavior of the AWT changed in an unfavorable way. An initial Frame whose coordinates aren't specified can no longer be located on the window system by the window manager without the application specifying exact coordinates for the new window. The desired behavior is to have the window manager tile new windows and not require the application programmer to have to add this type of logic to their code.  

In previous JDK versions, the underlying default window manager position was used which resulted in a tiling of new windows as they were created. In JDK1.1.5, the window's initial screen position is always in the upper left hand corner of the screen resulting in overlapping windows when multiple instances of applications are started. The overlapping window condition is very undesirable from a user-interface standpoint as the user is potentially unaware that more than the top window exists and they also have to always manually move their windows on their desktop to a suitable location.  

Verification on WindowsNT and Windows95: (Done by Ralph Karr, JavaSoft CTE)

Using JDK 1.1.2, 1.1.3, 1.1.4 and 1.1.5 the window initially always shows up at upper left hand screen position and getBounds() reports this position correctly.  
Using JDK 1.0.2 the windows initial position is determined by the underlying default window manager and getBounds() reports whatever the position is, correctly.  

Verification on Solaris 2.5.1 (CDE): (also done by Ralph Karr, JavaSoft CTE)

Using JDK 1.0.2, 1.1.2, 1.1.3 and 1.1.4 the windows initial position determined by the underlying default window manager and getBounds() reports a wrong position of (0,0).  Using JDK 1.1.5 the window initially always shows up at the upper left hand screen position and getBounds() reports this position correctly. 

For more background, please reference CTE Escallation 511847. 

Name: krT82822			Date: 03/10/2000


java version "1.2.2"
Classic VM (build 1.2.2-L, green threads, nojit)


Same bug as #4102292 - except there is no mention of these specific window
managers: Sawmill, Enlightenment.  These window managers are becoming very
popular, and are being used under the GNOME desktop.  For many Linux newbies,
this will be the default.

The problem:
Start any JFrame app that doesn't specify the initial window position (which
means the OS/window manager should pick one).  (The Notepad demo app does this.)
The JFrame appears at 0,0 with the titlebar and left edge of the frame off
screen - which means you can't move the window (unless you are using virtual
desktops.)

No matter what the selections are in the window manager, this is where the
window is placed.  Interactive/non-interactive doesn't matter.  The window is
just blindly placed there.
(Review ID: 102327)
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b16
14-06-2004

WORK AROUND One suggested workaround was to pick an initial window position in the middle of the screen somewhere. Subsequent window positions can now be calculated and positioned at absolute locations based on an offset from the initial window's position. This offset would be enough to allow the title bar that the window manager adds to be visible. This workaround pushes functionality of the window manager down into the application where it should not be. Customers don't like to have to do this and it not a good solution to have to present to them. Name: krT82822 Date: 03/10/2000 (Review ID: 102327) ======================================================================
11-06-2004

SUGGESTED FIX Allow the window manager to pick initial Frame locations which tile along with the rest of the windows on the desktop. Don't use the upper left hand screen position as the default if the application doesn't specify an initial location with setLocation() method.
11-06-2004

PUBLIC COMMENTS New AWT Frame with no specified initial coordinates always pops up in upper left hand screen location. This behavior is different than previous versions of the JDK.
10-06-2004

EVALUATION The problem is that the AWT currently has no internal mechanism to determine whether the 0,0 location of the window was set by the program or just there by default (because no location was set). It is true that the default location for a window should be a platform- dependent value (this is especially important for X11, where different window managers might have different policies about window placement). The AWT would need to track whether or not the location was "set" by the program (using a bit flag) and if it wasn't it should just allow the window to "default" to whatever location is appropriate for the platform. (and once the window is mapped to the screen, the location value in the Window object should be updated to reflect that value). amy.fowler@Eng 1998-09-29 06/28/1999 sandeepk@eng: Tested the user reported bug under Solaris 2.6 with JDK 1.2.2. The bug is reproducible. One suggestion for a solution would be to have a system property that is set to the intended default behavior. Another suggestion would be to provide a pluggable interface for managing window placement (something like Swing's PLAF). Window placement management is predominantly aesthetic and requires a heuristic solution. michael.martak@Eng 1999-08-10 Commit to Tiger ###@###.### 2001-09-28 This does not require an API change and should at least be partly fixed for hopper (top priority). ###@###.### 2001-11-08 Deferred to Mantis or Tiger, depending on resources. ###@###.### 2002-07-24 Recent discussions seem to imply that we need an API change to handle this correctly, which means it cannot be done before Tiger. ###@###.### 2002-11-07
24-07-2002