ICQ Lite window greys out after second launch

VERIFIED WORKSFORME

Status

Core Graveyard
Java: OJI
VERIFIED WORKSFORME
17 years ago
8 years ago

People

(Reporter: jonathanjohnsson, Assigned: Joe Chou)

Tracking

Trunk
x86
Windows 95

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

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

17 years ago
wfm using build 2001122108 on Linux + JRE 1.3.1_01.
(Reporter)

Comment 2

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

16 years ago
Closing as WFM per reporter's last comment.
Please reopen if proplem still persists
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 4

16 years ago
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.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---

Comment 5

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

pi
..and don#t forget to update to Java 1.4
(Reporter)

Comment 7

16 years ago
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
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 ;)
..wfm
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → WORKSFORME
v
Status: RESOLVED → VERIFIED

Updated

8 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.