116436 - ICQ Lite window greys out after second launch

Status: VERIFIED WORKSFORME

(Core Graveyard :: Java: OJI, defect)

Description

[jonathanjohnsson]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.7+) Gecko/20011221
BuildID:    2001122103

After the applet ICQ Lite is started the second time, the small window, that's
supposed to contain the applet, first shows the usual "Läser in Java-applet ..."
(starting Java applet in Swedish). Then the window simply greys out, and nothing
more happens.



Reproducible: Always
Steps to Reproduce:
1. Go to http://web.icq.com/icqlite/ . 
2. Click the large green button to start ICQ Lite (it starts as expected, using
the jre shown in additional information).
3. Close the ICQ Lite window.
4. Click the large green button again.

I didn't know where to put a workaround in this form, so here it goes:
1. Start the Java Console.
2. Type "x" ("clear classloader cache").
3. Close the Java Console and then click the large green button. The applet
starts as expected.

Actual Results:  The window that's expected to contain the ICQ Lite applet,
simply greys out after it has shown the usual "Starting Java applet", and does
nothing more. Output to the Java Console shown in additional information.

Expected Results:  The applet should have worked the same way the second time as
the first time.

The Java Console, with "trace level 5" shows (the console was cleared before the
second launch of ICQ Lite):

Java(TM) Plug-in: Version 1.3.1
Använder JRE-version 1.3.1 Java HotSpot(TM) Client VM
Användarens hemkatalog = C:\WINDOWS

----------------------------------------------------
c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
l:   dump classloader list
m:   print memory usage
q:   hide console
s:   dump system properties
t:   dump thread list
x:   clear classloader cache
0-5: set trace level to <n>
----------------------------------------------------

Registered modality listener

Referencing classloader: sun.plugin.ClassLoaderInfo@147496, refcount=1

Added trace listener:
sun.plugin.navig.win32.AppletPluginPanel[Start,0,0,177x424,invalid,layout=java.awt.BorderLayout]

Sending events to applet. LOAD

Sending events to applet. INIT

Sending events to applet. START

Determine if the applet requests to install any HTML page

HTML Installation finished.

Determine if the applet requests to install any JAR

Jar cache option: null
Jar archive(s): null
Jar cache version(s): null

Applet Installation finished.

java.security.AccessControlException: access denied (java.lang.RuntimePermission
modifyThread)

	at java.security.AccessControlContext.checkPermission(Unknown Source)

	at java.security.AccessController.checkPermission(Unknown Source)

	at java.lang.SecurityManager.checkPermission(Unknown Source)

	at sun.applet.AppletSecurity.checkAccess(Unknown Source)

	at java.lang.Thread.checkAccess(Unknown Source)

	at java.lang.Thread.stop(Unknown Source)

	at s.p(Unknown Source)

	at Start.init(Unknown Source)

	at sun.applet.AppletPanel.run(Unknown Source)

	at java.lang.Thread.run(Unknown Source)

Comment 1

[Olivier Cahagne]

wfm using build 2001122108 on Linux + JRE 1.3.1_01.

Comment 2

[jonathanjohnsson]

This problem doesn't appear using Mozilla 0.9.8 with the Sun JDK 1.4.0 on
Windows 98 SE. Maybe the ICQ Lite applet has also changed since I reported this bug.

Comment 3

[Denis Antrushin]

Closing as WFM per reporter's last comment.
Please reopen if proplem still persists

Comment 4

[jonathanjohnsson]

The problem still persists (with the same configuration as of my first report of
this bug: Win 95B, JDK1.3.1) with Mozilla 1.0 RC3 (Mozilla/5.0 (Windows; U;
Win95; en-US; rv:1.0rc3) Gecko/20020523). The address to the ICQ applet is now
http://go.icq.com. The console output is identical to that of my first report. 

Another problem is that the ICQ applet now starts without any clicking in the
page (as default), so if you accidentally come back to the ICQ applet start
page, the applet is reloaded, and your message sessions are lost. This doesn't
happen in Internet Explorer, so I suppose the pages use code that Mozilla
doesn't understand.

Yet another problem with the applet is that it is impossible to send messages to
other users. Everything looks fine, except that messages just don't get
transmitted to the receiver when pressing "Send". The console message is:


Trace level set to 5: basic, net, security, ext, liveconnect ... completed.

Exception occurred during event dispatching:

java.security.AccessControlException: access denied (java.lang.RuntimePermission
accessClassInPackage.sun.audio)

	at java.security.AccessControlContext.checkPermission(Unknown Source)

	at java.security.AccessController.checkPermission(Unknown Source)

	at java.lang.SecurityManager.checkPermission(Unknown Source)

	at java.lang.SecurityManager.checkPackageAccess(Unknown Source)

	at sun.applet.AppletSecurity.checkPackageAccess(Unknown Source)

	at sun.applet.AppletClassLoader.loadClass(Unknown Source)

	at java.lang.ClassLoader.loadClass(Unknown Source)

	at java.lang.ClassLoader.loadClassInternal(Unknown Source)

	at Start.p(Unknown Source)

	at j.v(Unknown Source)

	at j.i(Unknown Source)

	at j.a(Unknown Source)

	at af.i(Unknown Source)

	at af.actionPerformed(Unknown Source)

	at java.awt.Button.processActionEvent(Unknown Source)

	at java.awt.Button.processEvent(Unknown Source)

	at java.awt.Component.dispatchEventImpl(Unknown Source)

	at java.awt.Component.dispatchEvent(Unknown Source)

	at java.awt.EventQueue.dispatchEvent(Unknown Source)

	at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)

	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)

	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)

	at java.awt.EventDispatchThread.run(Unknown Source)


If it's of any interest, the next version of the ICQ applet, an alpha version,
found on the same page, doesn't exhibit any of the problems listed above.
Instead of not sending the message, it sends it, but shows an error window,
saying it's unable to play sounds. So probably, when the next version of the
applet is final, this problem is gone.

Comment 5

[Boris 'pi' Piwinger]

The ICQ version was updated. Do you still have a problem with Mozilla 1.1b or
later on this page or anywhere else?

pi

Comment 6

[Kai Lahmann (is there, where MNG is)]

..and don#t forget to update to Java 1.4

Comment 7

[jonathanjohnsson]

I have no longer any problem with running the applet under the JDK 1.3.1. It
still says that it cannot play sounds, but I don't need that. I'm not completely
sure if I should mark the bug as FIXED or as WORKSFORME, but I think FIXED
should be it. 

Kai Lahmann: JDK 1.3.x isn't very old yet, and JDK 1.4 came out only half a year
ago, so I think Mozilla should support it.

Comment 8

[Kai Lahmann (is there, where MNG is)]

I know, but that doesn't change the fact, that it is (at least on Linux) _very_
unstable.

and btw. this should have been wfm ;)

Comment 9

[Kai Lahmann (is there, where MNG is)]

..wfm

Comment 10

[Kai Lahmann (is there, where MNG is)]

v