Teamcenter Enterprise is a multi-tier database application. Its web
tier uses JSP/Servlets and also uses non-visual, non-interactive 
applets to interact with the main HTML content using JavaScript.

In the past, Netscape 4.x was a supported platform, and EDS developed
applets and utilities to use Java 1.1 to leverage browsers' built-in
JVM. The Java to JavaScript communication works very well when the JVM 
is built-in to the browser.

Now they moved away from using the built-in JVM because both Netscape 6
and IE 6 stopped shipping with a built-in JVM. There was also a requirement 
to move away from Java 1.1 due to the age of the technology and the lack 
of robust capabilities. (Java 1.3.1 is the current minmimum requirement).

Then it's discovered that in Netscape 6, 7 the Java-JavaScript communication
is broken on all platforms (Windows, Solaris, and HP). It's due to some 
combination of bugs in Netscape and the Java Plug-in. Most of the applets
use Java-JavaScript communication so this makes them completely unusuable.
The browser hangs when these pages are loaded.

EDS has tried a number of workarounds to try to bypass the bugs, but none
of them have worked so far. The things they tried are basically re-writing
parts of their code, for instance, creating fewer threads or threads in
different places. They tried this two times and in each case the fix worked
around the problem only far enough to run into a different problem or a
different manifestation of the same problem.

Due to the  customer  of the problem (hang) and the lack of Java Plug-in 
diagnostics, they are basically relying on blind luck and they cannot
be confident any given approach really solves the problems in all cases.

Although there is a option to just support NS 4.7.x, this will seriously
impact their efforts to improve the look and feel of the product, as
well as, not allow them to meet the product and customer commitments. The
basic commitment/requirement issue is the support of dynamic html, which
generally needs Netscape 6.x or later.

To help debug the issue, a pre-configured system (SB 2000) is being shipped
to the CTE group (Calvin Cheung, 408-276-7390). The machine has been installed
with all software pieces required to run TcE application. 

The system can be reconfigured to be standalone or networked like a server.
The root password is "root'. The trust user-name for Teamcenter Enterprise
is "pdm" and its password "pdm001". If you have access to the machine, login
as "pdm" and follow the directions in $HOME/READMEs:

   startServer.README - steps to start Oracle, Teamcenter Enterprise, Tomcat
   runWebClient.README - how to access TcE web client using Netscape 4.7.6,
                         Netscape 6.2.3 and Netscape 7
   license.README - how to reconfigure license in case of hostname change
   shutdownServer - steps to shutdown all servers.
   bugDescriptions - describes stops to reproduce the problem using "Checkin
                     with attachment Operation"
                     
You can test it from a remote system if the server is properly started.
Here are steps to reproduce the problem:

- Access the Teamcenter Enterprise Home page
        http://IPAddress:8019/TCPC

- Login
        Enter the User ID and Password:
                User ID: super user
                Password: <empty>
        Click "OK"

- Select/Create a Document to work with
        Type in * in the text field above the search
        button (on the left) and click "Search".

        It should return a Document that was created
        before from the database. Click the name of
        the Document "DesignDoc,A,1,1", which expands
        details about the selected Document.

- Attach a local file to the select Document
        Click a link "More file ..."
        Next, click the "Add Local File" button
        Click "Browse..." to select a non-empty file, then "OK"

- Check in this Document with the attachment we've just added
        Click "Check In" at the top
        Click "..." to select TCPC as Vault, then click "Next" button

        If it is Netscape 6.2.3 or 7, the browser will be frozen at
        http://IPAdress:8019/TCPC/controller/eds_mydata_link_checkin_to_vault_search 
        The browser is no longer functional.

        But for Netscape 4.7.6, the Check in operation proceeds to
        http://IPAddresshost:8019/TCPC/controller/eds_mydata_link_prepare_checkin_to_vault_browse
        Click "Browse.." button to make sure the attached file can
        be found in the location as indicated in "File Location/Name".
        Make sure "Yes" is filled by the application before clicking "OK".

        The Internet Explore has no problem. I found some inconsistency
        in Netscape 4.7.6, which works in a Solaris machine, but does
        not work on the other one. 

I have tested Java Plug-in 1.4.2-beta-b19 in both Netscape 6.2.3 and Netscape 7.
But it does not help.
  xxxxx@xxxxx   2003-05- customer 

Some Java applet source codes are placed in the machine under /scratch/pdm/applet_src.

  xxxxx@xxxxx   2003-05- customer 

N/A

Calvin is waiting for the machine and he will set it up on Monday. After that, we can work together to see where the problem is.

  xxxxx@xxxxx   2003-05-02
----------------------------------------------

Received a SunBlade 1000 and a monitor from MDE and the machine has been setup in the sustaining lab.

Host name : eds-plm.sfbay.sun.com
IP address: 10.5.20.120

To run the testcase from a remote machine within SWAN, just go to:
http://eds-plm.sfbay.sun.com:8019/TCPC

I've run some test using the runNetscape7 script.
The script will invoke netscape 7 with java plugin 1.4.1-b21.

Following the test steps, the browser appeared to be hung when a AccessControlException appears at the java console. See attached j141_console.txt. When the browser froze, the java console was still functioning.

After granting all permission by creating a .java.policy file at the home directory of pdm user with the following entry:
// Standard extensions get all permissions by default

grant {
        permission java.security.AllPermission;
};

The browser hang problem disappeared but I saw file not found exception at the java console. See attached j141_console_filenotfound.txt. Looks like there're some missing applet's jar files.
  xxxxx@xxxxx   2003-05-05

The problem of browser hang is due to the wrong security context passed from browser side. When Javascript calls Java, browser side constructs a "nsCSecurityContext" and passed to the Java Plug-in side. And Java Plug-in evaluates the Java call based on this securityContext. See the code below from SecureInvocation.java:

        // Set up virtual JavaScript Protection Domain
        ProtectionDomain[] domains = new ProtectionDomain[1];

        // Obtain proper protection domain for the call
        if (isUniversalJavaPermission == false)
            domains[0] = getDefaultProtectionDomain(origin);
        else
            domains[0] = getTrustedProtectionDomain();

        AccessControlContext context = new AccessControlContext(domains);

"isUniversalJavaPermission" is passed from browser side. The browser side set this information during the construction of nsCSecurityContext, see code below(mozilla/modules/oji/src/nsCSecurityContext.cpp).

 // Do early evaluation of "UniversalJavaPermission" capability.

     PRBool equals;
     if (!principal || 
         NS_SUCCEEDED(principal->Equals(sysprincipal, &equals)) && equals) {
         // We have native code or the system principal: just allow general
         m_HasUniversalBrowserReadCapability = PR_TRUE;
         m_HasUniversalJavaCapability = PR_TRUE;
     }
     else {
         // Otherwise, check with the js security manager.
            secMan->IsCapabilityEnabled("UniversalBrowserRead",&m_HasUniversalBrowserReadCapability);
secMan->IsCapabilityEnabled("UniversalJavaPermission",&m_HasUniversalJavaCapability);
     }
}

The js security manager has no idea about the signed jar file, so the m_HasUniversalJavaCapability is finally set to be false. 

So there is a flaw with the current security mechanism of javascript to java communication. And the fix should be in Java side since browser has no diea about whether the jar file is signed or not. The fix should look something like:

SecureInvocation.java

	// Set up virtual JavaScript Protection Domain
        ProtectionDomain[] domains = new ProtectionDomain[1];

        // Obtain proper protection domain for the call
        if (isUniversalJavaPermission == false && "clazz IS NOT in Signed jar")
            domains[0] = getDefaultProtectionDomain(origin);
        else
            domains[0] = getTrustedProtectionDomain();

        AccessControlContext context = new AccessControlContext(domains);

I am not sure whether we have an API to determin whether a class is coming from a signed jar or not. But logically speaking, we should be able to do it. 

This bug is not a regression. It does not work for Netscape/Mozilla on both Windows & Solaris platforms. The reason IE does not have this problem is because IE does not worry about security at all for javascript to java call.

I reassign this bug to Calvin Cheung and I think we should fix it in an update release since it will be risky to fix in Mantis.

  xxxxx@xxxxx   2003-05-06

Java Plug-in executes the java method with all permissions only if the JavaScript is signed which is according to the LiveConnect security policy. We do not plan to change this behaviour 
  xxxxx@xxxxx   2004-02-26

We offer customers the option of integrating javascript
menus with our applet. This bug means that in Netscape 7+
this feature just does not work. This is a show stopper for
some of our customers who need to migrate to Netscape 7. We
do not want to have to advise them to use Microsoft Internet
Explorer, nor are we happy building a work around involving
threads launched from init being held and then released by
the javascript. This will get very messy very quickly since
we will need to keep reusing the idea.
A fix would be good.

I reported this as bug 4806873 back in January and I was 
told:  
> This is correct behavior. When unsigned javascript calls
> signed applet,  method call runs on untrusted security
> context of javascript, instead of trusted security context
> of applet.

We have this problem as well, and it is a show stopper. we
have a complex javascript->java calls that works nicely with
explorer but not with mozilla.
We have gone through the obfuscated html signing, but still
no go. the java methods called from the javascript are not
priviliged. any idea/workaround will be greatly appreciated.

I have the same problem, but since 1.4.2_01 it is worse than
before: IE has the same problem (with 1.4.2 it worked, so we
decided to use IE, but now ...). Please, let IE be "unsafe"
like before until you correct this bug.

I just started investigating what appears to match this bug in 
the context of a regression with IE 6 when migrating from JRE 
1.4.1 to 1.4.2_02.  It disables an application which has been 
in production for years.

This is a showstopper to us -- to explore alternatives, we 
also tried VBScript with IE, all fails in 1.4.2_02!!  We really 
need a quick fix or reasonable workaround.

 I have succeded with this workaround:

1) In the 'init()' method of the applet I start a thread
that has the code that makes potentially unsecure actions
(access to disk, etc.).

2) The code in this thread is stopped before the actual
process begins, waiting for a signal to continue. I used a
Latch object , but it can be done with 'wait' and 'notify'
as well.

3) I have a public method in the applet that "wakes up" the
thread, allowing the "potentially dangerous" code to be
executed. As this method is available through JavaScript but
it doesn't do anything "dangerous" by itself (only calling
'notify' on an object, which in turn allows an independent
"process" previously started to continue), I can do the same
without the "access denied" exception.

  The key here is to start a Java thread with the dangerous
process started INSIDE the signed applet (in the 'init()'
method, for instance), but stopped until an internal
variable changes its state (e.g. a Latch). The JS code will
call a public method that only changes the state of the
internal variable (which is a "secure" action).

  Hope this helps.

 It worked for me !!!