Customer has an issue with the bug fix introduced into 1.4.0_02 for bug 4092033.

Method window.toFront() has been changed with fixed bugID 4092033 for java vm
1.4.0_02. Basically there is still a fundamental difference between Solaris/CDE and Win32
desktops.

If activation is done programmatically on right click - when
heavy weight components are used - a click with left mouse into heavy weight
components region lying in area outside parent window - may lead to activation
oscillations in z-order.

Bug fix 4092033 leads to endless loops of window activation in z-order disabled.

Generally due to reasons of different windowing behaviour of Solaris/CDE versus
Win32 window managers - one basic difference is that a child dialog popup will
always be in highest z-order position on win32.

On Solaris/CDE there may occur a z-ordering struggle between activated window
and child popup getting the focus. Attached please find a small demo program that introduces its selve, describes and demonstrates the following problem: If we open a popup window (which is a JWindow) that is not focusable (because we do not want it to get the focus) in front of an entry window, this window is set behind the entry window if the user clicks onto it so that it is covered by that window.

Because of that, the popup is unusable on Solaris/CDE.

This problem exists only on Solaris/CDE, please run the PopupDemo also in a
Windows environment to observe the correct behaviour.

To execute the demo program please detach it and type at the console:
    java -jar PopupDemo.jar


It is currently (with JRE 1.4.0_02 or later) not possible to bring a window to
front and to activate (which means set the focus to) another window.

It is very important for someone writing graphical user interfaces to be able
to:

a) set a window to front but leave the focus where it is

b) set the focus to a window but without setting it to front

c) tell a window that it is on top of all other windows and that it must stay
there, no matter what other window receive the focus or what other window is clicked with the mouse, but other windows must be focus and usable.

a) and b) is most important: I must be able to do a) and b) independently from
each other, but currently a) and b) are coupled, which means that is it currently impossible
to set the focus to another window than that one which is currently on top, and this is the real problem behind all.

This problem came with JRE version 1.4.0_02 and is probably a result of bug fix
4092033.

Test case attached.