34753 - Browser hangs loading signed Java applet.

Status: VERIFIED FIXED

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

Description

[William C. McCain]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; N; Win98; en-US; m14) Netscape6/6.0b1
BuildID:    2000033112

Netscape 6 Preview Release 1 hangs loading a signed Java applet that requests
privileges (using the "netscape.security" classes, such as
"ForbiddenTargetException" and "PrivilegeManager").  This works perfectly in
current releases of Netscape Communicator!  (Microsoft Internet Explorer
provides similar, but different, support for signed applets.)  As best as I can
tell, Netscape 6 Preview Release 1 simply does not support the
"netscape.security" classes.

Have you implemented yet annother INCOMPATIBLE security scheme?  It was bad
enough having TWO of them (Netscape and Microsoft)!  Do we now have to worry
about a THIRD incompatible security scheme for signed Java applets???


Reproducible: Always
Steps to Reproduce:
1. Load the reference URL
(http://www.novell.com/products/host/infopub/demos/gsdemo.html).
2. [There is no step 2 -- because it HANGS.]


Actual Results:  The Web page hangs.  The Java console displays:

JAR cache enabled.
java.lang.NoClassDefFoundError: netscape/security/ForbiddenTargetException
          at java.lang.Class.newInstance0(Native Method)
          at java.lang.Class.newInstance(Unknown Source)
          at sun.applet.AppletPanel.createApplet(Unknown Source)
          at sun.plugin.AppletViewer.createApplet(AppletViewer.java:1073)
          at sun.applet.AppletPanel.runLoader(Unknown Source)
          at sun.applet.AppletPanel.run(Unknown Source)
          at java.lang.Thread.run(Unknown Source)

If the browser instance is closed, the following additional messages appear in
the Java console:

java.lang.NullPointerException: null pData
          at sun.awt.windows.WComponentPeer.hide(Native Method)
          at java.awt.Component.hide(Unknown Source)
          at java.awt.Window.hide(Unknown Source)
          at java.awt.Component.show(Unknown Source)
          at java.awt.Component.setVisible(Unknown Source)
          at sun.plugin.navig.win32.PluginObject.setWindow(PluginObject.java:201)




Expected Results:  The Java applet should load and display a large rectangle
with a black background that emulates an IBM 3270 terminal.  Try the reference
URL under Netscape Communicator 4.7 to see the expected result in detail.


The reference Web page also uses the LiveConnect interface between JavaScript
(in the HTML file) and the Java applet.  The LiveConnect interface also appears
to be broken, as I reported in bug #34746.

In the present case, the JavaScript is very simple, consisting mainly of data
(and one small function that displays a JavaScript "alert" box when a function
key is pressed or an on-screen button is clicked).

The actual Java applet in this case is quite complex.  The privileges that it
requests are "UniversalSystemClipboardAccess" and "UniversalPrintJobAccess".
The "privilege granting" dialogs never appear.

I can supply the source code for the Java applet if necessary.

Comment 1

[William C. McCain]

In response to a number of requests, I have downloaded the most recent milestone
build of mozilla and have re-verified this bug there. Build ID: 2000022820.

This bug does exist in the mozilla milestone build, and it operates (and
isolates) exactly as I previously reported.

Comment 2

[edburns]

Signed applets are not yet implemented.

I'm reassigning this to George, who owns OJI.

Comment 3

[drapeau]

We're working on hooking up security again in current Mozilla and Java Plug-In
builds.  We expect to have delivery by Beta 2.  Putting in M17 as what I am
guessing is the closest Milestone to Beta 2.

Comment 4

[stanley.ho]

In Netscape 6, the old security model of Netscape JVM will not be supported 
anymore. It means that you should not use netscape.security.PriviledgeManager. 
Instead, you should simply sign your applet using Netscape signtool, and it 
will work as signed applet. This is not really a bug, but a compatibility issue 
between Netscape 4.x and Netscape 6.

Comment 5

[William C. McCain]

Unfortunately, I am not in a position to make any changes to the product that 
uses the "old security model of Netscape JVM".  I have retired, after 30 years 
as a software engineer in Silicon Valley.  And my former employer, Novell, Inc., 
no longer has anybody assigned to that product -- although it is a current 
product and is actively marketed.

Quite frankly, I am sure that the withdrawal of the 
"netscape.security.PrivilegeManager" classes is a MAJOR incompatibility that 
will adversely affect thousands of software products from HUNDREDS of vendors.

If you are moving to a simpler security model, in which signing the applet is 
sufficient, then I STRONGLY SUGGEST that you ship a set of "dummy classes" that 
implement the "netscape.security.PrivilegeManager" interfaces but which actually 
DO NOTHING.  This will permit existing signed applets to load and execute, 
without incurring a "java.lang.ClassNotFoundException"!!!

That way, at practically no cost to you, you will maintain backward 
compatibility with the thousands of signed applets that are already "out there".

Permit me, if you will, to get up on my "graybeard soapbox".  If there is one 
rule that I have learned in 30 years of product development, it is this:

NEVER BREAK BACKWARD COMPATIBILITY WITH YOUR OWN PREVIOUS PRODUCT.

Because, if you don't observe this rule, you will NEVER stop "hearing about it" 
...

William C. McCain
Novell Fellow Emeritus (retired)

Comment 6

[drapeau]

Just a comment update: we're going to try to get new security working for M16;
after that, we'll examine backward compatibility, see how much we can support.

Frankly, we'd like to deprecate the old security model so that the world can
start using the new one.  But William McCain, your point is well-taken.

Since you're retired, do you think you could spend some cycles in your copious
spare time helping with some bug fixes?  :-)

Comment 7

[William C. McCain]

I have no problem with deprecating the old Netscape 
"netscape.security.PrivilegeManager" security classes, as long as it is done the 
way the Sun does it: the compiler produces warning messages, but the code still 
compiles -- and runs.  And as I pointed out previously, it isn't even necessary 
for the "netscape.security.PrivilegeManager" methods to actually WORK as they 
used to (unlike Sun's typical deprecation, which maintains full functionality -- 
at least for the next few releases, which takes a few years).

In this case it would (probably) be sufficient to have "dummy classes" that 
satisfy the class loader and present the original, documented Netscape APIs.  
The methods could just "do nothing" and return (where required) simple default 
values.  But, since you are apparently abandoning Netscape's rather complex 
dynamic security model in favor of Sun's simpler static model, the Netscape 
security methods would no longer cause security dialogs to "pop up" for user 
intervention at run time  The user would see just the load time dialogs called 
for by the static model.

I am not sure you all appreciate the enormity of the "compatibility nightmare" 
that would ensue if existing signed applets that utilize the existing Netscape 
security model, are not allowed to load and execute without failure.  The fact 
is that there are just two security models that are widely used out there in the 
"real world".  One is Netscape's dynamic model, and the other is Microsoft's 
static model (which, ironically, is closer to Sun's model).  Sun's own static 
model, which was introduced in Java 1.1, has never been widely used on the Web. 
 It is available to both major browsers (Netscape Communicator and MSIE) when 
Sun's "Java Plug-in" is installed in lieu of the browser vendor's own Java 
support -- but that has never "caught on" in the Web at large.  It is used only 
by "us software developers" and perhaps on some corporate intranets (where it is 
possible to enforce a standard browser configuration by "corporate fiat").

The two extant security models are thoroughly incompatible: besides the 
conceptual differences (dynamic versus static, one with a security API and one 
without) they have different certificates, different signing tools, and 
different file formats (JAR and CAB).  But Web page designers have been able to 
cope with this because Microsoft had the decency (unusual for them) to provide 
MSIE with proprietary HTML keyword extensions that identify the Microsoft file 
format for signed applets (CAB).  Thus, it became standard (even easy) to write 
Web pages that enable Netscape Communicator to download its signed applets from 
JAR files while MSIE downloads its own proprietary versions from CAB files.

What I am getting at is this: if you don't allow enough backward compatibility 
for existing Netscape signed applets to load and run (under Netscape 6), the 
alternative is quite ghastly -- because there will then be THREE incompatible 
security models in wide use on the Web.  You might then be forced, 
Microsoft-like, to add a new proprietary HTML keyword that would identify a 
different JAR file for Netscape 6 to use for downloading an applet.  Or, almost 
as unsavory, Web page designers would be forced to add JavaScript code that 
tests for the browser being used (Netscape 6 versus 4.x or earlier) and 
generates the appropriate standard HTML for downloading the applet from a 
different JAR file in each case.

Comment 8

[ekrock's old account (dead)]

Marking crash. Java crasher-->nsbeta2. Java on b2 list. 

Comment 9

[leger]

Putting on [nsbeta2+] radar for beta2 to fix the hang.

Comment 10

[edburns]

Using 23 May 2000 NON-debug mozilla and 22 May 2000 Java Plugin, This doesn't 
hang the browser, possible due to bug 40723.  George, can you reassign this to 
Stanley?

java.lang.ClassFormatError: sx (Bad magic number)

	at java.lang.ClassLoader.defineClass0(Native Method)

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

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

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

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

	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:1101)

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

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

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

Comment 11

[edburns]

dependency

Comment 12

[drapeau]

Re-assigning to Stanley Ho, based on Ed Burns's recommendation.

I didn't understand the last comment by Ed, though: Ed, what did you mean by
"dependency"?  What is dependent on what?

Comment 13

[edburns]

George, I made this bug depend on 40723.

Comment 14

[Blake Ross]

http://www.novell.com/products/host/infopub/demos/gsdemo.html not crashing for 
me 60308 win ME

Comment 15

[John Unruh]

Marking fixed. The Browser no longer hangs loading signed Java applet, which was 
the original purpose of the bug.

Comment 16

[John Unruh]

Verified.