84412 - Browser lockup on Java initialization

Status: RESOLVED WONTFIX

(Core Graveyard :: Java: OJI, defect, P3)

Description

[Matthew Darwin]

From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (X11; U; Linux 2.2.14-5.0 i586)
BuildID:    20010503108

On the pop-up window, there are 3 java applets, only one is visible.
Once the visible applet draws (the status bar), mozilla locks up
solid.

Reproducible: Always
Steps to Reproduce:
1. Bring up url
2. Click the big logo on the left
3. enter login/password
4. wait


Actual Results:  once the status applet draws, mozilla is frozen

Expected Results:  mozilla should not freeze.  When pressing either the "traffic
light"
button or the "tree" button applets should launch.

These applets work fine in Netscape 4.7x.  They have not been
in any way changed for Mozilla.  They are signed applets and
require LiveConnect to work to interact with the toolbar buttons.

Further details available upon request.

Comment 1

[Phil Schwartau]

Confirming with Mozilla debug build 2001-06-05 WinNT. 
OS: Linux --> All. I am using this Java plug-in on WinNT: 

  File name: D:\mozilla\dist\WIN32_D.OBJ\bin\plugins\NPOJI600.dll
  Java Plug-in 1.3.0_01 for Netscape Navigator (DLL Helper)


I'm not sure whether to say, "Applets must use the XPConnect API now - 
not LiveConnect" - is that right? Or is this a bug in Mozilla?

Reassigning to OJI component; cc'ing Sean, Xiaobin, Patrick 

Comment 2

[Patrick C. Beard]

So as not to spread mis-information, the mantra is "plugins must use XPConnect
to be scriptable rather than LiveConnect", but LiveConnect is still supposed to
be supported for Java. That's the whole point of LiveConnect, it is a bridge
between Java and JavaScript.

That said, we need to do a thread dump and understand why Java is locking up
Mozilla.

Comment 3

[edburns]

Marking INVALID until I get a USERID and PASSWORD to test with.

Comment 4

[Phil Schwartau]

Reopening, because we have the required information.
Use test account: USERID=demo, PASSWORD=guide

Comment 5

[edburns]

We've got a security exception:

java.lang.SecurityException: class "com.loran.map.NetworkMapApplet4"'s signer 
information does not match signer information of other classes in the same 
package:

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

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

	at java.security.SecureClassLoader.defineClass(Unknown Source)

	at java.net.URLClassLoader.defineClass(Unknown Source)

	at java.net.URLClassLoader.access$100(Unknown Source)

	at java.net.URLClassLoader$1.run(Unknown Source)

	at java.security.AccessController.doPrivileged(Native Method)

	at java.net.URLClassLoader.findClass(Unknown Source)

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

	at sun.plugin.security.PluginClassLoader.findClass
(PluginClassLoader.java:240)

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

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

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

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

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

	at sun.plugin.AppletViewer.createApplet(AppletViewer.java:1184)

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

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

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

I'll ask Stanley how to fix this.

For what it's worth, the browser does not lock up.  It takes a while, but 
eventually it starts working.  This is probably due with the Lazi Loading fix 
for bug 26516.  Same result on Linux.

Comment 6

[edburns]

Since the browser doesn't lock up, and the security exception is "correct 
behavior".  I'm marking this is WONTFIX.

On 14 June 10:33:38, Jeff Nisewanger wrote:
> 	As of JDK 1.2.2 we enforce a security restriction that requires
> all classes in the same package (loaded by same class loader and in the
> same package name) to have the same code signers. This is intended to
> prevent
> a style of security attack which attempts to gain access to package
> private access to signed classes in a jar.
> 
> 	One workaround is to repackage the jar file(s) that contain classes
> in the same package and either remove the signatures or re-sign the
> classes
> with the same keys.

Comment 7

[shrirang khanzode]

SPAM: reassigning OJI bugs to new QA, pmac. (227 bugs)

Comment 8

[Patty Mac]

Chris Petersen is a new QA contact for oji component. His email is:
[e-mail]

Comment 9

[Matthias Versen [:Matti]]

fixing small error for [e-mail] (filter with : SPAMMAILSUCKS)