86634 - The user interface blocks while loading java jre plugin

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Java: OJI, defect, P3)

Description

[Ilya Konstantinov]

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?

Comment 1

[Tim Powell]

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

Comment 2

[shrirang khanzode]

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

Comment 3

[edburns]

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

Comment 4

[Ilya Konstantinov]

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?".

Comment 5

[Kathleen :Brade]

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

Comment 6

[Xiaobin Lu]

   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. 

Comment 7

[Tim Powell]

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.

Comment 8

[shrirang khanzode]

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

Comment 9

[shrirang khanzode]

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

Comment 10

[shrirang khanzode]

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

Comment 11

[edburns]

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

Comment 12

[Joe Chou]

Re-assign to nidheesh.

Comment 13

[Nidheesh Dubey]

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

Comment 14

[Peter Lubczynski]

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.

Comment 15

[WD]

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

Comment 16

[WD]

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

Comment 17

[David G King]

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

Comment 18

[Peter Lubczynski]

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

Comment 19

[Patty Mac]

Chris Petersen is a new QA contact for oji component. His email is:
[e-mail]

Comment 20

[Matthias Versen [:Matti]]

fixing small error for [e-mail] (filter with : SPAMMAILSUCKS)

Comment 21

[Joshua Xia]

reassign to me

Comment 22

[Joshua Xia]

->kyle

Comment 23

[Ricard]

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

Comment 24

[Pete Zha]

mass reassign to Alfred

Comment 25

[John Pham]

Any progress on this bug? 

Comment 26

[Dmitriy]

JRE 5.0.11 - bug exists.

Will be this bug fixed any time?

Comment 27

[Aaron Lawrence]

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

Comment 28

[Benjamin Smedberg]

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