FULL PRODUCT VERSION :
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-beta-b19)
Java HotSpot(TM) Client VM (build 1.4.2-beta-b19, mixed mode)

FULL OS VERSION :
 customer  Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
My Webstart application has an initial popup (a JDialog) which asks the user for login information, and this JDialog is created before any JFrame.

When launched via Webstart, Webstart's "Desktop Integration" prompt (which asks the user "Would you like to have 'appname' integrated into your desktop environment?" fights for focus with my app's initial JDialog.  The Webstart prompt seems to put itself on "top" of my dialog, it is impossible to select any of the Webstart choices because actual focus remains on the JDialog.

Once my app's login dialog has been filled in and is gone, the user can then make a choice on the Webstart "Desktop Integration" prompt.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
I have the testcase below available via Webstart at http://www.classgrabber.com/webstart/focus.jnlp

The "real application" (non-testcase app) is available at http://www.classgrabber.com/webstart/agent.jnlp
When Webstart's "Desktop Integration" comes up, select "Ask later" so you can repeat the problem (If you select "Yes" or "No", web start won't prompt anymore).


EXPECTED VERSUS ACTUAL BEHAVIOR :
As in previous versions, Webstart doesn't actually run the application until the user has answered Webstart's prompt "do you want to add this item to your desktop".  This avoids focus problems.
Since Webstart now runs the application while the Webstart "Desktop Integration" prompt is still up, there is a "fight for focus" and it is confusing to the user.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.*;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import javax.swing.*;

/**
 * AVAILABLE AT: http://www.classgrabber.com/webstart/focus.jnlp
 * Focus test case for webstart problem.
 * PLEASE NOTE that even though this JDialog doesn't have any input fields,
 * in my real app, there are input fields, and it is confusing to the
 * user where the focus is.
 */

public class FocusProblem {
	public static void main(String args[]) {
		JFrame frame = new JFrame() {
			public Dimension getPreferredSize() {
				return new Dimension(200, 100);
			}
		};
		frame.setTitle("Debugging frame");
		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		frame.pack();
		frame.setVisible(false);

		JDialog dialog = new JDialog(frame, true);
		dialog.getContentPane().add(new JLabel("foo"));
		dialog.addWindowListener(new WindowAdapter() {
			public void windowClosing(WindowEvent event) {
				System.exit(0);
			}
			public void windowClosed(WindowEvent event) {
				System.exit(0);
			}
		});
		dialog.pack();
		dialog.setVisible(true);
	}
}

---------- END SOURCE ----------

Release Regression From : 1.2
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

(Review ID: 183475) 
======================================================================

configure desktop integration as "allways" or Never"

This is a regression, in that previous versions synchronously asked user for desktop integration.  Problem only occurs for application that start with modal dialog that comes up 2 - 8 seconds after launch. (before 2 seconds, the desktop integration dialog will be last modal dialog, after 8, desktop integration dialog dosn't try to put itself on top).
Problem is easy to work around (after 8 seconds, bring applications modal dialog to the top, and answer it.) but still annoying.
Java Web Start should not bring the Desktop Integration Dialog to the top over
another modal dialog.
should fix for tiger.

  xxxxx@xxxxx   2003-04-10

What version number is Tiger ?
I Hope this is 1.4.2, because that's really a problem for
customers. In previous versions, our application would not
be started until the desktop dialog has been deal with.

I really hope you will fix it so it behave the same.

We must at all cost avoid customer call to their help
center... And trust me, those customer call for less than
this ;-)

I hope this problem gets fixed for 1.4.2 because it will prevent 
us from upgrading to 1.4.2 if it is not fixed.

Sorry 64chuck, this hasn't been fixed in 1.4.2...

Can you include this in 1.4.2_02 or 1.4.2_03, instead of Tiger?

The real problem here is the Java Webstart team is now being 
punished for using a shared VM before the Isolation API is 
ready.  Using a shared VM was always way too ambitious for 
my liking.  A noble cause for sure, but the risks inherent in 
running JWS in the same VM are too large as demonstrated by 
this problem (and it is a huge problem, half the webstart apps 
I've tried today failed).  The risks are even greater with a 
Swing App as there is only one event dispatcher between two 
apps.

For anyone else out there that wants to change their JNLP to 
work around this madness, try forcing the app to use 1.4.1.  
This will force JWS to spawn a new VM which will have its 
own dispatch thread.

It might be worth asking Sun if they have any undocumented 
flags/tags to prevent JWS from sharing a VM with your app.

Please fix this. Webstart is great, but its advantage is
lost if customers  have to wait additional 8 seconds before
they can log in the application. I plan to install a
webstart intranet app in 4 weeks, please fix this within
this time. 

We have even worse problems caused by this, our app starts 
with a modal login dialog - when this clashes with the desktop 
integration dialog the latter pops to the front. This  obscures 
the our login dialog completely and is also inoperable; in that 
none of the buttons work, nor can the integration dialog be 
minimised nor moved. After messing with the task manager to 
hide the frozen integration one we can proceed to login, but 
when then our main app appears it is now disabled and the 
hidden integration dialog is now active.. so when have to 
hunt for this dialog and accept/dismiss it before user can run 
the app.. Of couse we can't allow users to upgrade to 1.4.2 
with this kind of bug.

Fixed ? Well please back-port this fix for the next 1.4.2
revision please !

My customer has just ordered an update for 1.4.2 and
webstart that should be installed  on september the 1st. But
I don't know how to go on without a fix for the conflict
between modal login dialog and desktop integration popup. If
tiger is higher than 1.4.2.x it doesn't help for me. Please
apply the fix to 1.4.2.x to save my work.

I hope the workaround "configure desktop integration as
'allways' or 'Never'"  isn't the "fix".  It is still broken
for people who don't want to configure desktop integration
as "always" or "never".  

I posted a solution to this thread:

http://forum.java.sun.com/thread.jsp?forum=38&thread=430741

(snip)
* The workaround is activated for 8 seconds if Java WebStart
1.4.2
 * is detected. After 8 seconds it will deactivate itself if
it is
 * still active. In that time frame, if a WindowEvent about the
 * Desktop Integration Window is intercepted, the window
will be disposed.
(snip)

Hi Martin, Thanks for your bugfix class WorkAround4845341(). 
It looks great, so I have integrated it and had a try. 
It shows
WA4845341: Detected Java WebStart 1.4.2
WA4845341: Started.
... 8 seconds
WA4845341: Stopped.
as expected. Nevertheless the desktop integration popup 
appears - around 1 second after the message "WA4845341: 
Started." I have difficulties to understand this. I thought 
there is only one event queue...

Hi nadenn,

Lets continue this discussion on the forum :

http://forum.java.sun.com/thread.jsp?forum=38&thread=430741

If you have fixed the bug why don't you don't you apply the
fix to software thats available. If you want to have success
with java fix the bugs and don't develop only for the
future. Why do I develop in java at all if it promises much
- but fails. And: this problem is not "easy to work around".
Waiting additional 8 seconds is not acceptable if a fast
application startup is needed.