The user interface blocks while loading java jre plugin



18 years ago
6 years ago


(Reporter: ilya.konstantinov+future, Unassigned)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: redesign)



18 years ago
Steps to reproduce:
1. Install Sun's JRE.
2. Go to 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

18 years ago
Yes. Confirming. This happens on WinNT with 2001061304. OS -> All. Is this a
general plug-in loading problem or OJI?
Ever confirmed: true
OS: Linux → All
Hardware: PC → All

Comment 2

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

Comment 3

18 years ago

*** This bug has been marked as a duplicate of 1785 ***
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 4

18 years ago
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
"How can we make it less painfull to the user?"
"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

18 years ago
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).
Keywords: perf
Resolution: DUPLICATE → ---

Comment 6

18 years ago
   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

18 years ago
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

18 years ago
i'm with tpowell on this one....

Comment 9

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

Comment 10

18 years ago
SPAM: reassigning all OJI bugs to new OJI QA, pmac ( 227 bugs)
QA Contact: shrir → pmac

Comment 11

18 years ago
Ressign to Joe Chou, as I am no longer working officially on OJI.
Assignee: edburns → joe.chou
Target Milestone: --- → mozilla0.9.6

Comment 12

18 years ago
Re-assign to nidheesh.
Assignee: joe.chou → nidheesh
Target Milestone: mozilla0.9.6 → mozilla0.9.9

Comment 13

18 years ago
This problem is generic to all plugins. When the plugin loads UI does not
respond. Check with Sockwave as well.
Assignee: nidheesh → av
Component: OJI → Plug-ins
QA Contact: pmac → shrir

Comment 14

18 years ago
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.
Assignee: av → peterl
Priority: -- → P3
Hardware: All → PC
Summary: The user interface blocks while loading Java → The user interface blocks while loading JRE 1.3.x
Whiteboard: [FIXED in JRE 1.4]
Target Milestone: mozilla0.9.9 → Future

Comment 15

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

Comment 16

17 years ago
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
Summary: The user interface blocks while loading JRE 1.3.x → The user interface blocks while loading java jre plugin

Comment 17

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

Comment 18

17 years ago
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

Assignee: peterl → joe.chou
Component: Plug-ins → OJI
QA Contact: shrir → pmac
Whiteboard: [FIXED in JRE 1.4]
Target Milestone: Future → ---

Comment 19

17 years ago
Chris Petersen is a new QA contact for oji component. His email is:
Assignee: joe.chou → petersen
fixing small error for (filter with : SPAMMAILSUCKS)
Assignee: petersen → joe.chou
QA Contact: pmac → petersen

Comment 21

17 years ago
reassign to me
Assignee: joe.chou → joshua.xia


16 years ago
Whiteboard: redesign?


16 years ago
Whiteboard: redesign?


16 years ago


16 years ago
Whiteboard: redesign

Comment 22

15 years ago
Assignee: joshua.xia → kyle.yuan


14 years ago
Assignee: yuanyi21 → pete.zha

Comment 23

13 years ago
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

13 years ago
mass reassign to Alfred
Assignee: zhayupeng → alfred.peng

Comment 25

12 years ago
Any progress on this bug? 

Comment 26

11 years ago
JRE 5.0.11 - bug exists.

Will be this bug fixed any time?

Comment 27

11 years ago
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...
Assignee: alfred.peng → nobody
QA Contact: chrispetersen → java.oji


9 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard
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".
Last Resolved: 18 years ago6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.