Problem accessing the [object Window] from JavaScript.



19 years ago
8 years ago


(Reporter: leilag, Assigned: stanley.ho)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta2-], URL)


(3 attachments)



19 years ago
Using 10/11/99 Mozilla build on WinNT and jdk1.3 ea.
Using 10/13/99 Mozilla build on MAC and MRJPlugin092499 from Mark Lin.

To reproduce,
- Load
- Click on any of the 2 buttons.
  This supposedly would show the value of an applet variable which value is a
Window object which is the result of getWindow(this).
  On WinNT, this would crash the apprunner. On MAC, this wouldn't give any
  display or response but wouldn't crash the apprunner.

The URL below would also exhibit the same problem.


19 years ago
Target Milestone: M12

Comment 1

19 years ago
The description of this test does not coincide with my copy of the referenced
page. Mine pops an alert displaying the value of the window variable. Is that

Comment 2

19 years ago
Created attachment 2866 [details] [diff] [review]
Bug fix. patch 1 of 2 (liveconnect)

Comment 3

19 years ago
Created attachment 2867 [details] [diff] [review]
Bug fix. patch 2 of 2 (oji)

Comment 4

19 years ago
The above patches provide a partial fix to this bug. The problem is that during
conversion from a JS object to a Java object, the unwrapping code assumes that
the object was wrapped as a native netscape.javascript.JSObject, when in fact it
was wrapped by the plugin as a sun.plugin.javascript.navig5.JSObject. Tof
fix this I've added code in two places:
1. To the JSJCallbacks table (jsjava.h), I've added a function called
unwrap_java_wrapper that is the mirror of the function get_java_wrapper. The
plugin should provide the implementation of this callback. In the meantime, the
callback is set to NULL.
2. Temporary workaround code that knows the internal structure of
sun.plugin.javascript.navig5.JSObject, so that it can get the wrapped object
directly. Once the plugin implements the unwrap function, this workaround should
go away.


19 years ago
Target Milestone: M12 → M13

Comment 5

19 years ago


19 years ago
Target Milestone: M13 → M14

Comment 6

19 years ago
move to m14. let me know if fixes are available. thx.

Comment 7

19 years ago
I have reviewed the patch, and it looks good.

Comment 8

19 years ago
Putting Raju Pallath on the CC: list of this bug, as he is taking over the 
Sun/Blackwood QA role from Leila Garin.  (if there's a way to change the 
reporter of this bug from Leila to Raju, that would rock).

Comment 9

19 years ago
Changed Qa contact person from  Leila to Rpallath
QA Contact: paw → rpallath

Comment 10

19 years ago
Jeff, I tried this URL with  build of Mozilla dated 03/05/2000 and used JRE-RC1
(from JDC site) and applied the patch plugin zip file (from George).

Loaded the URL and clicked on the Alert Button. It crashed the Browser.
DO I still have to apply the patch or is it already in place in the source base.

Comment 11

19 years ago
Created attachment 6213 [details]
Tar file for the example test case.

Comment 12

19 years ago
I check in part of the fix last night. We now need to get some work done in the 
plugin for resolution. With last night's (3/6) changes, it doesn't crash.

Comment 13

19 years ago
After Jeff's checkin, it doesn't crash.  No longer Stability blocker.  Moving 
to M16.
Target Milestone: M14 → M16

Comment 14

19 years ago
Nominating for nsbeta2.  Also, adding Stanley Ho to the CC list on this bug so
he can check with his latest build of Java Plug-In.  This *should* be fixed,
looking for verification from the engineers responsible for the code fixes.

LiveConnect needs to work for Beta 2.
Keywords: nsbeta2

Comment 15

19 years ago
Putting on [nsbeta2+][6/01] radar.  This work must be done by 06/01 or we may 
pull this for PR2.
Whiteboard: [nsbeta2+][6/01]

Comment 16

19 years ago
Changing from [6/01] to [6/15]
Whiteboard: [nsbeta2+][6/01] → [nsbeta2+][6/15]

Comment 17

18 years ago
Cleaning up the status whiteboard by setting to beta1 minus (6/15 has passed)

Based on the comments, this bug might actually be fixed... and if so... we 
should mark it and get it verified.
Whiteboard: [nsbeta2+][6/15] → [nsbeta2-]

Comment 18

18 years ago
M16 has been out for a while now, these bugs target milestones need to be 

Comment 19

18 years ago
Tried this with build of mozilla dated 7/7/2000.
Used Plugin (Version 1.3-0-netscape-pr2)

It does not crash but it throws a security Exception java.lang.IllegalAccessException
        at java.lang.reflect.Field.get(Native Method)
        at Method)
        at sun.plugin.liveconnect.SecureInvocation.GetField(SecureInvocation.jav

Will try to see if passing it appropriate permissions would enable it to access

Comment 20

18 years ago
This security exception will go away when the plugin implements the unwrap 
function mentioned in my comment above. The ball is in Stanley's court. I'm 
happy to help.

Comment 21

18 years ago
Per today's OJI meeting, assigning this to Stanley.
Assignee: drapeau → stanley.ho

Comment 22

18 years ago
Jeff, how should I implement unwrap_java_wrapper() if it is not a XPCOM 
interface? We should probably talk about it.

Comment 23

18 years ago
We need to add to nsIJVMPlugin:

NS_IMETHOD UnwrapJavaWrapper(JNIEnv* jenv, jobject jobj, jint* obj) = 0;

The OJI function:

static jint PR_CALLBACK
unwrap_java_wrapper_impl(JNIEnv *jEnv, jobject java_wrapper)

Is then just a proxy for the nsIJVMPlugin call. The guts of this function are 
the same as you'll find on lines 307 through 309 of 

If you want this fix in for Netscape 6 RTM, please nominate for nsbeta3 and
explain in the Description the impact of not getting this fixed. Thanks!

Comment 25

18 years ago
This problem have been fixed by implementing UnwrapJavaWrapper() as described 
by Jeff. Changed state to fixed.
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 26

18 years ago
Verified per stanley.ho's comments.


8 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.