Closed
Bug 116436
Opened 23 years ago
Closed 23 years ago
ICQ Lite window greys out after second launch
Categories
(Core Graveyard :: Java: OJI, defect)
Tracking
(Not tracked)
VERIFIED
WORKSFORME
People
(Reporter: jonathanjohnsson, Assigned: joe.chou)
References
()
Details
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•23 years ago
|
||
wfm using build 2001122108 on Linux + JRE 1.3.1_01.
Reporter | ||
Comment 2•23 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•23 years ago
|
||
Closing as WFM per reporter's last comment.
Please reopen if proplem still persists
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 4•23 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•23 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
Comment 6•23 years ago
|
||
..and don#t forget to update to Java 1.4
Reporter | ||
Comment 7•23 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
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Updated•23 years ago
|
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Comment 8•23 years ago
|
||
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•23 years ago
|
||
..wfm
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•