14711 - JavaScript to Java SecurityApplet test freezes apprunner.

Status: RESOLVED INCOMPLETE

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

Description

[Leila Garin]

Using my Sept. 14 Mozilla build and jdk1.3 on Windows NT.
Added the npjava*.dlls to bin/plugins directory.

To reproduce,
 - Bring up LiveConnect/html/SecurityApplet.html
 - Click "Read Local File" or "Write Local File" or "Delete Local File" buttons.

   Notice that apprunner will freeze.

Comment 1

[Leila Garin]

Attachment: tar file of LiveConnect tests.

Comment 2

[Jeff Dyer]

Control does not return from the show method of java.io.FileDialog. Here is
a summary of the code in the Java Plugin that gets us there:

1. This method is called through JNI.

SecureInvocation.CallMethod()
{
    ProtectionDomain[] = new ProtectionDomain[1];
    domains[0] = new JavaScriptProtectionDomain(securityContext);
    AccessControlContext context = new AccessControlContext(domains);
    …
    return AccessController.doPrivileged(new PrivilegedCallMethodAction(
                                               method,obj,args), context);
}

2. doPrivileged calls the run method on PrivilegedCallMethodAction.

PrivilegedCallMethodAction.run()
{
    return method.invoke(obj,args);
}

3. The applet method, doFileRead is called via method.invoke. A new FileDialog
object is created, but the show method never returns control. No exception is
thrown.

SecurityApplet.doFileRead() {

    dlg = new FileDialog(…);
    dlg.show(); // does not show dialog or return control to caller.

}

Somebody in the Java Platform group should probably take a look at this.

Comment 3

[drapeau]

Contacted JDK folks at Sun for more info about a possible Java Plug-In problem
here.  The preliminary response was that this problem sounds like one that was
previously seen in the Java Plug-In implementation for Internet Explorer.  If
so, a similar fix could be applied to JPI (Java Plug-In).

More status to follow; this bug probably won't be closed for a couple of
milestones, if it is indeed in JPI.  It will take some time for the JDK folks to
get to a full evaluation, considering where they are in their own JDK release
cycle (i.e., not much time to evaluate these bugs at the moment).

Comment 4

[drapeau]

Re-setting the milestone on this one, and copying Stanley Ho so that he's aware 
of the problem.  We'll start worrying about security issues after Beta 1.

Comment 5

[drapeau]

This may turn out to be a security problem, which is being worked on for M16. 
Will have Jeff Dyer look at this bug when he has completed security work.
Also nominating for Beta2, since security is the main feature going into OJI for
Beta 2 and this should be taken care of by then.

Comment 6

[leger]

Putting on [nsbeta2+] radar for beta2 fix. 

Comment 7

[leger]

Putting on [nsbeta2-] radar. Sun would need to take care of this.

Comment 8

[Mike]

M16 has been out for a while now, these bugs target milestones need to be 
updated.

Comment 9

[edburns]

Moved Target milestone to M18.

Comment 10

[edburns]

Per OJI meeting today, assigning to Jeff.

Comment 11

[Jeff Dyer]

This bug should be fixed when Java plugin learns how to use  
nsScriptSecurityManager to check permissions. No ETA yet.

Comment 12

[ekrock's old account (dead)]

Nom. nsbeta3 in crash category. (We know it freezes apprunner; anyone know if
the same is true in Mozilla or N6?)

Comment 13

[edburns]

Reassign to stanley.

Comment 14

[edburns]

Per Stanley's request, marking future.

Comment 15

[Michael La Guardia]

marking nsbeta3- per last comment

Comment 16

[rpallath]

Tried this with mozilla build 09/22 (around PR3 branch time) wiht new PR3 Jre
bits (09/22).

Still hangs on NT/98.

Comment 17

[rpallath]

Just for information

Checked on Solaris sparc 2.8 with FCS bits of Java Plugin 1.3.0_01
and FCS package of Netscape 6 for Solaris dated (12/4)
It does not hang.

Comment 18

[Alexei V. Mokeev]

With 2001052904 nigthly build, under WinNT SP4 and jdk1.3.0_02 this testcase
just crashed Mozilla.
1)Start Mozilla
2)Load SecurityApplet.html
3)Click on any button(read, write or delete)
=> Mozilla crashed with dialog "Memory at 0x000 couldn't be read"

Comment 19

[Alexei V. Mokeev]

Same build is crashed with jdk1.3.1 too.

Comment 20

[Paul Wyskoczka]

Changed qa contact to [e-mail]

Comment 21

[fremea]

04;4;Avril

Comment 22

[Benjamin Smedberg]

Mass-closing bugs in the "OJI" component: OJI plugin integration was replaced with npruntime long ago, and these bugs appear to be irrelevant now. If there is in fact a real bug that remains, please file it new in the "Core" product, component "Plug-ins".