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)

x86
Windows 95
defect
Not set
normal

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)
wfm using build 2001122108 on Linux + JRE 1.3.1_01.
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.
Closing as WFM per reporter's last comment. Please reopen if proplem still persists
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
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 → ---
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
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 ago23 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
Closed: 23 years ago23 years ago
Resolution: --- → WORKSFORME
v
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.