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,  xxxxx  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,  xxxxx  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. 




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)
======================================================================

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.   




(Review ID: 102327)
======================================================================

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).

  xxxxx@xxxxx   1998-09-29

06/28/1999   xxxxx@xxxxx  : 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.
  xxxxx@xxxxx   1999-08-10

Commit to Tiger
  xxxxx@xxxxx   2001-09-28

This does not require an API change and should at least be partly fixed for hopper (top priority).
  xxxxx@xxxxx   2001-11-08 

Deferred to Mantis or Tiger, depending on resources.  
  xxxxx@xxxxx   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.  
  xxxxx@xxxxx   2002-11-07

A Frame with no set size becomes VERY LARGE (32,000x32,000) when made visible
on
Solaris 2.5.1 (with JDK 1.1.3).
Most of the time the top-left-corner position puts the window manager title bar

out of bounds of the screen leaving it troublesome to move.

Maybe there should be some constants for
positioning windows, not at absolute positions,
but at specified points on the screen. In XFORMS
(Unix systems), you can display windows:
-in screen corners
-at the center of the screen
-at the mouse current position (ie generally over last click)
and IMHO this is a good solution.

We are seeing this in JDK1.1.6, and JDK1.2 as well.
We too, consider this a serious bug.

On X windows, I believe the ICCCM (the window manager standard)
tells programs to set the user position hints only when a position
is supplied by the end user (as with a -geometry command line option).
Java programs, beginning with JDK 1.1.5, are now violating this standard,
as the only way I know of enforcing the position is to set it as a user
position (the program position hints can be ignored by the window manager).
Given this, 4102292 should be a bug and not a request for enhancement.
I consider it fairly serious and users at my site are avoiding using 
JDK 1.1.5 because of this.

This is a serious bug.  I want to position my applications
using interactive placement with the fvwm or CDE window
manager.  Since 1.1.6 applications which haven't had a size
set for their frame come up with a tiny wire frame which
bears no relation to their true size.  Setting the position
using interactive placement has no effect:  the application
appears in the upper left corner of the screen if no explicit
position has been set.
The JDC applets suffer from this problem.

This is NOT an RFE, it's a bug, plain and simple.
Changed behavior that violates an existing standard
is a bug.
We've had a _bunch_ of problems involving window
sizes and placement since upgrading to 1.1.5 on
Solaris/2.6:
  - Windows going to (0,0) no matter what the
    window-manager wants (CDE, mwm, twm, tvtwm)
    That's this bug-report.
  - Windows flashing up at min-size at (0,0) 
    before "jumping" to their specified location.
  - Windows "lying" about their size and position
    by the size of their border/titlebar (see
    bug #4101910, I think).  Worse under mwm
    than CDE.
One would think that window-placement and
sizing would be a solved problem; why am I
spending so much time taking flak from
customers over the fact that their titlebars
show up off-screen??

On Win NT it is currently impossible to correctly position JFrames manually in
pure java as you cannot find the position of the start bar.
I believe the default position should be set by the OS/Window Manager. Also the
screen size should take taskbars into account so that we do not/cannot end up
clashing with them if we manually position.
If the window position is not defaulted properly by the VM how can we possibly
write portable applications. We would have to test our window positioning with
every window manager available. Hence we need absolute screen size as well as
usable screen size and location (if we can only have 1 screen size then I vote
it should be the useable area not the actual size).

This is indeed a very annoying BUG!  I tried the .Xdefaults workaround
but was unable to get it to work.  When I do an xwininfo my
application window has no name so I can't name it in the
defaults file????

Also, you might want to mention in your workaround that the method to call to
set the window initial location is Component.setLocation()!

OK, JavaSoft have done what I would have thought impossible:
they've made the situation *even worse* in JDK 1.2beta4.
To recap, I want to position the frame of my application
using interactive placement under the CDE and fvwm window
managers.  In JDK 1.2beta4 when I start my application I
get a wireframe to do the positioning, I put it where I want
it with a mouse click, it appears for a moment, then vanishes
and is replaced by a second wireframe!  When I position this
the application finally appears at (0,0), not where I put it.
Come on JavaSoft!  Find someone who _knows about X_!

For those interested, this is listed as a bug in
4123598.

Since upgrading from JDK 1.1.4 to 1.1.6-2 on 
Digital Unix the titlebars appear off-screen
with fvwm2. This is majorly annoying! It seems
to work with mwm. Please fix that bug!

just wanted to add i've put my three votes in for
this bug now.

This bug is really most annoying! Somehow they
managed it that it became even worse in 
Java 1.2beta4 as described above.
It shows up with any window of any Java 
application here on Sun Solaris / MWM, even with 
commercial progs like ICQJava. Come on Sun, there
must be someone who is able to fix this bug, no
other language programs have problems like this!!!
I have to say i'm getting really angry now. I hope
it will be fixed when i'll be finishing my diploma
work project, or people will go "nice project but
you didn't even fix the most obvious bug".

Comment on the Evaluation of "1998-09-29".  Originally,
whichever flag is set by the window manager to indicate
that "*interactivePlacement" is set was *not* being
ignored by AWT.  Only in recent AWT releases has this been
the case.  My XWindow programming is rusty, so I don't
what AWT should be checking, but that info is readily
available.... it was being used in older JDK releases.

Yes! Yes! Yes!
The bug finally made it to the top 25!

Sorry!
I had a geometry specification left in my .Xdefaults.
After removing everything works 100% ok here.
A big thanks to the Sun Java programmer team!!!

Hm...
in Java 1.2rc1 they have fixed it so that the 
window ALWAYS pops up at (100, 100). There is no
use calling setLocation on the main JFrame it seems.
However at least the annoying Miniwindow is gone.

I've just checked this in JDK 1.2 FCS.  Interactive
window placement now works with the CDE window manager,
but still not with fvwm.

I sure hope this fix (in 1.2) makes it into some 1.1 maintenance release so my
users can benifit as well.

An anonymous evaluator writes:
Window placement management is predominantly aesthetic
and requires a heuristic solution.
This may be so, but it isn't the job of the Java system
to implement such heurisitics:  that is the job of the
window manager.  Once I've configured my window manager
to use the heuristic that I find aesthetically pleasing
I expect it to be allowed to implement that behaviour
for all applications.
I have my window manager (fvwm on Solaris) set to allow
interactive placement of windows.  When I start up an
application the window manager lets me position a
wireframe outline of the application window.  Once
I've positioned it I expect it to stay there.  This is
what happens with native applications but not with Java
ones.  When a Java application is realised it will either
move to a position explicitly specified by the programmer
or it will got to the top left hand corner of the screen
if the programmer hasn't specified a position.  Either
behaviour is unacceptable, the latter particularly so.
The question isn't 'what hacks need to be put into Java
to allow it to position windows?', the question is 'why don't
Java windows respect the window placement setting of
the window manager?'

This bug did not exist in early versions of the JDK (see prior comments),
so the bottom line on this, it's a bug.  It used to work
correctly, and now it doesn't.   Changes in the whatever_awt.c code caused this
problem, and are likely to be able to be fixed there. 
I used to do a lot of X programming, but after all these 
years of Java, I can't help fix this bug.  Believe me, if
I could, I would, because this bug drives me *wild*
when having to explain to people I'm demoing what's going on
with Java applications.  This is a very embarassing bug to have
to explain.  PLEASE FIX IT.  It's been over a year now!

Happy birthday, bug 4102292!!
Two years old and still not fixed.

To the anonymous evaluator of 1999-08-10:
Unless you've got the whole platform built in a Java
environment, it is not the place of Java to handle the
placement of windows unless EXPLICITLY requested to do so by
the application programmer.  IOW, unless the app programmer
explicitly calls setLocation(...) on that object, the object
should express no preferred position, and it should then be
left entirely up to the enclosing Operating Environment (be
that the OS or the Window Manager) to perform the placement.

In terms that even someone not very knowledgeable should be
able to search for...
******************************************
  Do not set the USPosition bit in the flags field of the
XSizeHints structure that you pass to XSetNormalHints,
XSetWMSizeHints, or XSetWMProperties calls for a window
unless the program has called setPosition() on the Frame
object associated with that window.  On no account should
the AWT call setPosition() itself for non-Dialog windows!
******************************************
Come on Javasoft, the fix is not a tough one by any means...

Just for the record I'm seeing this bug on RedHat 6.1,
gnome/enlightenment, jdk 1.1.8, swing 1.1.1

When it's someone else's app (w/o source) there is no
workaround that I know of.

Still not fixed in JDK 1.3.0 beta on Solaris.

8.5 months since I pointed out exactly what is wrong, and
this is still open?  Shame on you, javasoft!  Had the JDK
been OSS, this would have been fixed ages ago...

Wow.

>Evaluation
>Commit to Merlin
>xxxxx@xxxxx 2001-03-06

Does this mean something is finally going to happen?  And
will it be a proper fix, not just some more workarounds for
particular window managers?

This bug has been in the database for over three years and
I've been tracking it almost daily for most of that time. 
It's the single most important thing that prevents me from
taking Java seriously as a client-side solution.

The Frame's coorinates is center to the screen 's center.
The Window and Dialog thant haven't owner need setLocation 
to the screen's center.
This is very necessary!

I just tried this under Merlin beta, and this has NOT been 
fixed.  :-(

I should clarify by what I mean by that....it doesn't work 
under fvwm, which is the window manager that I originally 
submitted the bug under (not this bug...someone else did 
this...mine was closed out because it was "fixed").

After years of asking about this when I got the chance, I 
finally gave up on this and I switched to CDE.  Too 
embarrassing showing people demos with the windows warping 
to the upper left hand corner, with the upper and left 
window decorations off screen.

This bug has not been fixed under Merlin beta2. What does
"Commit to Merlin" means?

dlemire asks 'What does "Commit to Merlin" mean?'

Well, the question is now academic because since it was
asked the evaluation has changed from "Commit to Merlin" to
"Commit to Tiger".

What *this* means is that Sun aren't serious about
supporting Java on Unix.  If they were they'd have taken
steps to fix this serious bug years ago, not postponed
dealing with it from one release to the next.

Until this is fixed it simply isn't possible to deploy
professional-quality AWT or Swing applications on Unix.

You can use dialog instead of frame and the window is 
relative to the parent, but it behaves badly with the 
browser on windows. It can get behind the browser and the 
only way to recover visibility is to minimize the browser.

This is definitely annoying but by no means 
insurmountable.  JDK 1.1.4-1.1.5-1.1.6-1.1.7 had serious 
issues on Win32 with window placement - some would place 
the window without the titlebar, others would include the 
title bar in the height, etc.  After a little work (which 
of course is working around a bug - not desirable, but 
possible) it was manageable and it was possible to ship a 
polished Java Swing app that worked on 
Linux/Solaris/Win32/Mac predictably.

So while this is serious, it won't make or break the 
platform.

Bugs like this are pretty annoying. This is more like a 
request for enhancement than a bug. You can easily extend 
Frame or JFrame and make it so that it positions and 
resizes appropriately. It is absolutely NOT true what some 
users have said here, along the lines of:

"Until this is fixed it simply isn't possible to deploy
professional-quality AWT or Swing applications on Unix."

When there are *serious* bugs out there (like 4337823 and 
4390238 etc.) it's a real shame that 180 people have wasted 
their votes on something as trivial as this bug!

Merlin and Tiger are names of JDK versions. "Commit to 
Merlin" means that Sun has commited to making a fix for 
this in time for the Merlin release of JDK.

This is really annoying!
Just like the other stupid bug: frame caption always says
"AWTapp".
Anybody knows about?

State : In progress, bug
Submit Date : Jan 07, 1998

4 years now. either Javs sucks and must die; or Sun sucks and must die.

I ditched a major Java project 2 years ago due to dozens of real bugs and minor insanities (like this one), because I had the firm conviction a this time that Sun would make no real effort to close them all, or at least make this real-world project simply work. all my team needed was bugfixes to a dozon critical bugs, with no real working workaround available.

Boys, I was right. Althought I was a Java fanatic, today I fell I simply saved my carrier.

If you Sun guys CAN'T fix the smallest bugs or misfeatures in FOUR years, I can't see why or how you could fix critical ones.

Even Microsoft manages to do that, what gives ?

Oh, for goodness sake!  'Deferred to Mantis' now.

Will this never be fixed?

1.1.5, 1.1.6, 1.1.7, 1.2, 1.2.1, 1.2.2, 1.3, 1.3.1, 1.4, ...

This is a regression, though it's difficult to recall that it ever 
worked in the first place at this point.  It takes more time to 
enter the evaluation than to fix this one.

This can't be done properly within an application, the tiling
isn't sensitive to other tiling being done by the OS.  This is 
simple to do, and will remove a LONG standing bug with MANY 
votes.

It just can't be much more difficult than:
private boolean locationHasBeenSet;
setLocation(Dimension) { locationHasBeenSet=true; ... }
show() { if(locationHasBeenSet) peer.setLocation(...); else 
leave peer's location alone; }

1.4.1 should have this, no excuses, no API change in this and 
regressions 4.5 years old should have a higher priority than 
_any_ new features.

This really does make every Java app look like an amateur 
toy. One cannot ship things that behave like this.

Happy birthday, bug 4102292!!

Five years old, 234 votes, third in Top 25 list and still no
sign of it being fixed.

5+ and still going strong
Please vote on this!!

Why are all the voting options "Empty vote"? I'd like to
vote for this but that doesn't sound too promising.

Empty vote means that the vote is not used yet. Just select 
one and click vote.

Oh, BTW the bug is present in 1.4.1 too.

Wow, congrats to Sun for finally listing this under "fixed"! I'ld 
be curious to read a synopsis of what the fixed behaviour now 
is though. I must say, long ago I wrote a handler class to 
aleviate many of these minor considerations within an 
application with a single line of code... If the VM can now do a 
better job (by linking to the system window manager), I would 
ask Sun to ensure there is at least some routine to test, within 
the VM, whether the VM is fixed, and can handle window 
placement, or not fixed (older VMs), and I need to handle it.

For more information about what Sun have done to work around
this problem see the Evaluation section of bug id 4401846.

Adding a system-property "java.awt.Window.locationByPlatform" is a bad way to fix this problem. Why don't you simply add an internal variable which keeps track if the window location has ever been set before or not. If so and the window has a location of (0,0) it should be placed their; if not, let the underlying window-manager handle the positioning. This is far more seamless than having the user manually select the behavior using a system property.

I am having this problem now. Is there any resolution for this