148498 - Can't reload Java applet

Status: RESOLVED WORKSFORME

(Core Graveyard :: Java: OJI, defect)

Description

[Koike Kazuhiko]

Java applet at <http://nk-money.topica.ne.jp/kawase/live.html>
doesn't work if you visit there for the second time.

Steps to reproduce:
(1) Load <http://nk-money.topica.ne.jp/kawase/live.html>. Java applet works.
(2) Jump to an another page and come back.

Comment 1

[Ian Neal]

Which build and JRE versions are you using?

Comment 2

[Robert Offinger]

User Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.0) Gecko/20020611
Build ID: 2002061103
and
User Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1a) Gecko/20020614
Build ID: 2002061401

Java(TM) Plug-in1.3.1_03

I have the same problem, too.

And I have a similar problem with the Java applets I use at my page
http://www.math.uni-magdeburg.de/~rooff/Schach/18sol.html
Here loading a second time freezes the browser. Worse, with 1.1a the applets
aren't even loaded once when I use the object tag notation, only when the
applet tag is used as at http://private.addcom.de/dxb/dxbpuzz.html it works
for the first loading attempt.

Comment 3

[Mark J. Reed]

I've had this problem with every applet I've tried on every Mozilla build to
date, including 1.1, on both Windows and Linux.  Restarting Mozilla works; on
Windows it also works if I use the Java Plug-In Console system tray application
to clear the classloader cache. But without one of those two steps, I can only
run a given applet once per session. 

Comment 4

[Joe Chou]

Re-assign to Ping.

Comment 5

[Jeremy]

We have experienced the same problem with the applet that the original reporter
mentions.  This applet is generated by the internal web server in the Canon
VB-C10 network video camera.  The camera itself runs embedded Linux and specs
may be found at http://www.x-zone.canon.co.jp/WebView-E/product/vbc10/index.htm.
 Our configurations are as follows:

Linux 2.4.18, 2.4.19
Mozilla 1.0 Final
Java versions: IBM, Blackdown, Sun (1.3.1, 1.4)

Both kernels and all Java distros do the same thing.  Sometimes the applet will
work properly upon reload.  Most of the time, however, it fails to work after
the first try AND disables the ability to run all other applets until Mozilla is
restarted (or the JavaVM threads are all killed).  

Comment 6

[Max Kanat-Alexander]

Is this still an issue? Can we get a trace of the Java VM, or the output of the
Java console when this bug happens?

Even the thread status at the time when it won't load any more applets would be
better than nothing.

-M

Comment 7

[Jan Carlin]

See Sun's bug 5009809. There is a workaround for this.

Comment 8

[Jan Carlin]

See Sun's bug 5009809. There is a workaround for this.

Comment 9

[Kyle Yuan]

Here is the work around if that matters.

"The issue is when a shift-reload is done in Mozilla, the classes are loaded
from the classloader.  Static classes are reloaded with the last value (or in
one instance corrupt value) which they were set when the previous applet is
destroyed, thus causing the applet to initialize incorrectly.  When creating the
components on a shift-reload, I have to explicitly set static values in methods."

Comment 10

[Pete Zha]

mass reassign to Alfred

Comment 11

[Hideo Oshima]

I can't reproduce anylonger with recent Linux trunk build.
Can anyone confirm this?

Comment 12

[Hideo Oshima]

It still works for me.
Marking WFM.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090211 Minefield/3.2a1pre