Java Applet not reloaded correctly if the page is refreshed

RESOLVED INCOMPLETE

Status

Core Graveyard
Java: OJI
--
critical
RESOLVED INCOMPLETE
10 years ago
5 years ago

People

(Reporter: André Kunert, Unassigned)

Tracking

unspecified
x86
Linux
Bug Flags:
blocking1.9.1 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9) Gecko/2008060309 Firefox/3.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9) Gecko/2008060309 Firefox/3.0

The mentioned URL contains an applet which is loaded successfully. After refreshing the page (Refresh-button in the toolbar), the threads of the currently running applet are stopped. The next try to start the applet fails. often it is necessary to kill the java_vm process to regain access to the firefox.
Opening the URL again via the address field in e.g. the same tab successfully loads the applet again.

I'm currently using:
Ubuntu 8.04
Sun Java Plug-in 1.6.0_06
According to the repository manager: Firefox 3.0 RC1

Best regards,
André

Reproducible: Always

Steps to Reproduce:
1. Open URL with an applet -> The applet should load successfully
2. Use the Reload/Refresh-Button of the browser to reload the page

Actual Results:  
- gray area where the content of the applet should have been displayed
- after several reloads, the sun logo with the progessbar is shown, but does not load anything

Expected Results:  
The applet should have been restarted.

Comment 1

10 years ago
I'm also facing this bug on several Ubuntu and Fedora systems
running different versions of Firefox 3.0

An additional URL would be this example applet from Suns
Java tutorials:

http://java.sun.com/docs/books/tutorial/uiswing/components/applet.html

Comment 2

10 years ago
I confirm this bug on Ubuntu Linux: (2.6.24-19-generic) and Firefox: (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008061015 Firefox/3.0) even with the simplest Java applet. Java console stack trace:

ava.lang.InterruptedException
	at java.lang.Object.wait(Native Method)
	at java.lang.Thread.join(Thread.java:1143)
	at java.lang.Thread.join(Thread.java:1196)
	at sun.applet.AppletPanel.run(AppletPanel.java:404)
	at java.lang.Thread.run(Thread.java:619)
basic: Exception: java.lang.InterruptedException
java.lang.InterruptedException
	at java.lang.Object.wait(Native Method)
	at java.lang.Thread.join(Thread.java:1143)
	at java.lang.Thread.join(Thread.java:1196)
	at sun.applet.AppletPanel.run(AppletPanel.java:404)
	at java.lang.Thread.run(Thread.java:619)
java.lang.ThreadDeath
	at java.lang.Thread.stop(Thread.java:715)
	at java.lang.ThreadGroup.stopOrSuspend(ThreadGroup.java:666)
	at java.lang.ThreadGroup.stop(ThreadGroup.java:580)
	at sun.awt.AppContext.dispose(AppContext.java:440)
	at sun.applet.AppletClassLoader.release(AppletClassLoader.java:752)
	at sun.plugin.security.PluginClassLoader.release(PluginClassLoader.java:441)
	at sun.applet.AppletPanel.release(AppletPanel.java:181)
	at sun.applet.AppletPanel.sendEvent(AppletPanel.java:292)
	at sun.plugin.AppletViewer.onPrivateClose(AppletViewer.java:1113)
	at sun.plugin.AppletViewer$4.run(AppletViewer.java:1062)
	at java.lang.Thread.run(Thread.java:619)

Comment 3

10 years ago
Suspect it's limited to Firefox for Linux from the following results.
Test case:
On all of these, I loaded up the National Weather Service Doppler radar, selected 'loop' and got a looping radar.  Then I selected either an adjacent region or 'loop composite' and it fails.

With latest FF(3.01) and java ((jre6u7) on sidux (kernel 2.6.20.1-slh-smp-2)  and apparently any other linux, reload fails with a message of applet [name] bail.  At this point, if you kill any of  the java_vm processes, it kills Firefox.  (Here, the [name] was AniS.)

With the same FF(3.01) on windows XP SP2, the problem does not show up.

With Opera (9.51) on the same sidux installation and the java (from the same directory) and even before updating jthe java , there were no problems.

Comment 4

10 years ago
I am experiencing this exact bug. It happens every time as described by #1.

I have found that going to Tools->Add-ons->Plugins and right-clicking the Java JRE and disabling, then re-enabling causes the applet to load properly when the page is reloaded again.
 
The Java Plug-in is version 1.6.0_06-b02 for my FF3 browser.  I suspect these problems are because it is a beta version??  I'm using Ubuntu with all the current updates.

Comment 5

9 years ago
I can confirm this bug.

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.0.3) Gecko/2008092416 Firefox/3.0.3
Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
(Reporter)

Comment 6

9 years ago
(In reply to comment #4)
> The Java Plug-in is version 1.6.0_06-b02 for my FF3 browser.  I suspect these
> problems are because it is a beta version??  I'm using Ubuntu with all the
> current updates.

Seems not to be a problem with the beta version. I'm currently using FF 3.0.3 and have the problem with Java Plugin 1.5 and 1.6.

Comment 7

9 years ago
I confirm this bug on Debian Lenny in Iceweasel (I hope it's okay anyway):
java version "1.6.0_07"
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008071618 Iceweasel/3.0.1 (Debian-3.0.1-1)

In addition, I have seen this behaviour:
This one will fail on reload, as this bug report suggests:
<applet code="EVDown.class" archive="EVDown.jar">

But if you change the archive attribute between page loads, it won't fail. This will work on page reloads:
<applet code="EVDown.class" archive="EVDown.jar?1222971978">

The numbers are generated by a server script, such as PHP.

I haven't found out if the applets stop() and destroy() methods are called.

Comment 8

9 years ago
Any Java developer in the audience has found any temporary solution?

I've tried several things unsuccessfully, but I though the error was due to another cause. Now, I don't have a clue as to what I could do, except wait.

BTW, this still happens in Ubuntu Intrepid (8.10 beta) and Hardy (8.4), both firefox and epiphany, and not in other browsers (konqueror, ie6, chrome, firefox over xp)

Comment 9

9 years ago
As suggested in the sister java bug

http://forums.sun.com/thread.jspa?messageID=10453337

use of icedtea plugin (based on openjdk and gcjwebplugin) instead of sun-java6 solves this problem.

Comment 10

9 years ago
In fact it seems the bug is not only when the page is refreshed but it’s also always reproducible with applets in a multi-frame page (probably linked with the refresh case).

Environment :
+ Firefox 3.0  (Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9) Gecko/2008052912 Firefox/3.0)
+ Ubuntu 7.04
+ Sun Java 1.6.0_07 (bug appears with 1.6.0_04)

Reproduction : 
+ Different pages load the same jar (a simple hello world applet) and they contain user links to switch between them. If these page are opened in a frame of a master page then the bug occurs when the first applet is destroyed (when the page changes).

Observations :
+ Applet of the new page : freezed UI or status “applet notinited”
+ Applet of the previous page when destroying : 
1.	status “applet bail”
2.	and sometimes the stack trace :

basic: Chargement de l'applet...
basic: Initialisation de l'applet...
basic: Démarrage de l'applet...
basic: completed perf rollup
Hello world !
basic: Thread d'applet joint...
java.lang.InterruptedException
                at java.lang.Object.wait(Native Method)
                at java.lang.Thread.join(Thread.java:1143)
                at java.lang.Thread.join(Thread.java:1196)
                at sun.applet.AppletPanel.run(AppletPanel.java:404)
                at java.lang.Thread.run(Thread.java:619)
basic: Exception : java.lang.InterruptedException
java.lang.InterruptedException
                at java.lang.Object.wait(Native Method)
                at java.lang.Thread.join(Thread.java:1143)
                at java.lang.Thread.join(Thread.java:1196)
                at sun.applet.AppletPanel.run(AppletPanel.java:404)
                at java.lang.Thread.run(Thread.java:619)
java.lang.ThreadDeath
                at java.lang.Thread.stop(Thread.java:715)
                at java.lang.ThreadGroup.stopOrSuspend(ThreadGroup.java:666)
                at java.lang.ThreadGroup.stop(ThreadGroup.java:580)
                at sun.awt.AppContext.dispose(AppContext.java:440)
                at sun.applet.AppletClassLoader.release(AppletClassLoader.java:752)
                at sun.plugin.security.PluginClassLoader.release(PluginClassLoader.java:441)
                at sun.applet.AppletPanel.release(AppletPanel.java:181)
                at sun.applet.AppletPanel.sendEvent(AppletPanel.java:292)
                at sun.plugin.AppletViewer.onPrivateClose(AppletViewer.java:1113)
                at sun.plugin.AppletViewer$4.run(AppletViewer.java:1062)
                at java.lang.Thread.run(Thread.java:619)


I tried to set different archive attributes for each page and it worked. Unfortunately I’m not in charge of the pages creation, so this workaround is useless to me.
Moreover it’s not applicable when applets which must share data (via static members for example) are created from the same jar : if we change the archive name (eg. with a suffix ?xxx) then the data are not shared anymore.

Note : the bug also sometimes appears (but not always reproducible) without frames.

(cf. attachement : Bug_438803_example.zip)

Comment 11

9 years ago
Created attachment 343373 [details]
Reproduction example for the bug 438803 (cf. comment #10)

Comment 12

9 years ago
I can confirm the bug in Windows XP SP2. It was introduced in this beta.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090123 Shiretoko/3.1b3pre

The browser is not able to restart the JVM on refresh.

Comment 13

9 years ago
Reload error on Windows was fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090128 Shiretoko/3.1b3pre.

Comment 14

9 years ago
I am using Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3 right now, and the bug is still there.

Updated

9 years ago
Flags: blocking-firefox3.1?
Assignee: nobody → smichaud
Component: General → Java Embedding Plugin
Flags: blocking-firefox3.1?
Product: Firefox → Core
QA Contact: general → java.jep
--> Core::Java Embedding Plugin

carrying over blocking nomination
Flags: blocking1.9.1?
This has nothing to do with the JEP -- which is Mac only.
Assignee: smichaud → nobody
Component: Java Embedding Plugin → Java: OJI
QA Contact: java.jep → java.oji
Is this something that's happening only with the old OJI based Java plugin, or does it happen also with the new NPRuntime based Java plugin? I.e. are you guys using libjavaplugin_oji.so or libnpjp2.so? If you're using libjavaplugin_oji.so, please try switching to the new plugin (libnpjp2.so). Please see http://java.sun.com/javase/6/webnotes/6u10/plugin2/#INSTALLATION for more information on doing so.
Oh, and I meant to say two more things, you can find out which plugin you're using in about:blank, and if it's the new Java plugin and you're still seeing this bug, please renominate (set the blocking1.9.1 flag to '?'). Not blocking on this unless someone can confirmed this is a problem with the new Java plugin.
Flags: blocking1.9.1? → blocking1.9.1-

Comment 19

8 years ago
see bug 271907 comment 1

Comment 20

8 years ago
I confirm this bug on x86_64 with SUSE operating system.

Kernel Details
===============
>cat /proc/version
Linux version 2.6.27.23-0.1-default (geeko@buildhost) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP 2009-05-26 17:02:05 -0400

Firefox Details
================
32-bit Firefox version 3.5.1

Java Plugin Details
====================
libjavaplugin_oji.so
Java(TM) Plug-in 1.6.0_04

Problem Details
-----------------

I used the multi frames and the applets loads for the first time and does not load the successive times. If I click on the link again the firefox is getting freezed and I have to kill the java process forcefully to get the control back.
Its really annoying. If someone has found a fix for the same please let us know.

Though I have tries using the 64-bit firefox 3.0.11 with IcedTea JDK and everythong works as expected without any errors. The applets loads fine all the time without errors.

Is this a problem with JRE version or the firefox version ?
Any Suggestions

Updated

7 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard

Comment 21

5 years ago
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".
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.