Steps to reproduce: 1. Install Sun's JRE. 2. Go to http://java.sun.com/ or any other site with a Java applet. Actual result: The user interface blocks ("freezes") completely while the Java Runtime is being loaded. Once the Java Runtime finishes loading, it works and UI responds as usual. This creates a noticable delay on my P733 workstation. Expected result: While the Java Runtime loads, the application continues to function as usual (probably leaving a rectangle for the applet which haven't loaded yet), slowing down the rest of the computer a bit obviously. After all, that's what we have a multitasking OS for, no?

Yes. Confirming. This happens on WinNT with 2001061304. OS -> All. Is this a general plug-in loading problem or OJI?

.this is due to the 'lazy jvm laoding' process...newly added. also this is a dup... cc: xiaobin.

*** This bug has been marked as a duplicate of 1785 ***

It's not a dup. Bug 1785 agrees with the incurred cost and UI blockage of loading Java (and offers more control on whether you'd wish to take that cost), while I'm talking about a more general issue - trying to change the perspective from: "How can we make it less painfull to the user?" to: "Why do we have this pain at all? Why do we have to settle with Java blocking the UI just cause it was so in the 4-years-old Netscape Communicator?".

reopen this bug; it doesn't sound at all like the bug I filed. This is a performance issue (or possibly just a threading or other timing issue).

The problem is caused by Patrick Beard's lazy loading fix for liveconnect ( a way for communication between Java and Javascript). The purpose of the fix is to make the browser start up quickly. Before the fix, when the browser starts up, a system classloader loads a lot of system classes such as java.lang.System, however, after that fix, we won't have that loading. These class loading was delayed to the first applet page you visit. After you have visited one page with applet, no delay will be happen for the rest applet you would like to see. So basically the problem you see here is a tradeoff between the browser startup time and applet loading time. As you may know, a lot of customer complains about the browser start up time, so we think it is worthy to do this.

I don't think that's what this bug is about. The point is that the ENTIRE UI of mozilla blocks while Java is loading. This shouldn't happen. The fact that it used to happen during start made it less noticable and less problematic. Is there a reason Java can't be loaded in a separate thread so that the UI stays responsive while Java is loading? I don't mind that the first Java applet is somewhat slow to load. What is troubling is that you can't interact with Mozilla during this time.

i'm with tpowell on this one....

i mean..user should be able to use mozilla while the applet is loading in the background..r whatever

SPAM: reassigning all OJI bugs to new OJI QA, pmac ( 227 bugs)

Ressign to Joe Chou, as I am no longer working officially on OJI.

Re-assign to nidheesh.

This problem is generic to all plugins. When the plugin loads UI does not respond. Check with Sockwave as well.

I disagree. I think Xiaobin is exactly right in comment #6. The problem is in the JRE 1.3, and the 1.4 beta3, is much, much better because it was probably designed with lazy loading in mind. Note: Mozilla is largely single threaded. Layout and the UI are on the same thread because they essentially are the same thing. Layout loads the plugin, so that's why the UI blocks. Try JRE 1.4 beta3.

*** Bug 139990 has been marked as a duplicate of this bug. ***

Updated summary to aid in searching BZ. I don't think JRE 1.4 fixes this, though. There is no UI interaction possible during the time when the java plugin is loading, even with 1.4

*** Bug 142452 has been marked as a duplicate of this bug. ***

JRE 1.4 doesn't take as long as 1.3 and 1.4.1 is even quicker. We will no longer load Java at startup so there is no way for Mozilla to fix this as described in comment #6. Sun needs to fix the JRE in future releases to "startup quickly". Perhaps loading can be done off USER events or another thread so it doesn't block the main UI thread? --->back over to OJI

Chris Petersen is a new QA contact for oji component. His email is: petersen@netscape.com

fixing small error for pmac@netscape.com (filter with : SPAMMAILSUCKS)

reassign to me

->kyle

Is anybody keeping track of this bug. The discussion is from 2003 and the loading of Java applets still blocks the UI. I find this really annoying and maybe something that could be fixed if the Java plugin loaded in a separate thread. Am I missing a point here? Why isn't this done? thank you

mass reassign to Alfred

Any progress on this bug?

JRE 5.0.11 - bug exists. Will be this bug fixed any time?

I don't know enough to tell for sure, but I think that Mozilla apps make little or no use of threading, perhaps for portability reasons. This means that loading the JRE in a background thread would be difficult. Also I imagine that the JRE itself possibly only allows itself to be loaded on the main thread - after all it must set up GUI stuff as well. So perhaps this is impossible to fix in the browser, and really a problem with the JRE...

Mass-closing bugs in the "OJI" component: OJI plugin integration was replaced with npruntime long ago, and these bugs appear to be irrelevant now. If there is in fact a real bug that remains, please file it new in the "Core" product, component "Plug-ins".