65250 - Opening a second window via window.open() prevents calls from Java into Browser window's javascript

Status: VERIFIED WORKSFORME

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

Description

[gary.kind]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001211
BuildID:    2000121104

I have a simple html file that fires off an Applet and creates a button. When
clicked, a second window is brought up by calling window.open().  The second
window has a button that sends its click event to the main window's javascript
and on to Java.  Java then attempts to call back into the main window's
javascript but a security exception results and is displayed in the java console.

Reproducible: Always
Steps to Reproduce:
1) Unzip the attached modalWin_test.zip file to construct the test case.
2) Go into the resulting modalWin_test directory and read the
   readme.txt file.
   a) run modalWin.html in the browser
   b) press the 'Show Modal window' button
   c) Up comes modal window, press the 'B1: Click Me' button
   d) Exception appears in the java console.

Actual Results:  A security exception appeared in the java console.  The
contents are in a file called java_console.txt that comes with the reproducible
case.

Expected Results:  Javascript function 'showAlert' (in file modalWin.html)
should have been called successfully and a javascript alert with the appropriate
message should have appeared.

The same exception occurs whether or not the second window is modal.  As long as
the window is alive, the exception occurs.

This bug prevents us from dynamically updating anything while the modal window
is up.  We will not be able to finish development of our product on Netscape 6
until this is fixed.

I am still looking at whether or not I can call into the modal window's
javascript -- it would seem to be rather difficult without the main window's DOM
window object.

Our dialog's change dynamically based on events, so it is essential that we be
able to call back into javascript when a dialog is up.

Comment 1

[gary.kind]

Attachment: Reproducible test case for bug #65250

Comment 2

[Phil Schwartau]

This is an excellent test case!
Reassigning to Jeff and OJI component; cc'ing Mitch for Security 

Comment 3

[ckritzer (gone)]

Hmmnn...

I think I understand what Gary's attempting to do with the testcase, but I see
this as a potential security risk if we allow this sort of access.

Something I don't understand (Gary/Phil/Mitch, feel free to vend me a clue) is
where the "JavaScript: UniversalBrowserRead enabled" and "JavaScript:
UniversalJavaPermission enable" is happening in the html, class or java files?
I see these two items popup in the Java console (running in trace level 5) when
I run the tests.

Comments, gentlemen?

Comment 4

[gary.kind]

I completely disagree with ckritzer's comment.  Our application gets events from
javascript -- both the main browser and any second (dialog) window.  We process
the event in Java (sometimes validating things on a middle-tier and in the
database) and respond to the event in a manner that makes sense for our product.
 It is completely reasonable that we would want to be able to dynamically update
the main Browser and, especially, the second dialog window from java.  A good
example would be responding to a TAB keypress to do our own navigation from Java
in the second window (I will refer to it as the dialog window from here on out).
 How can we do this if we cannot call into the dialog's DOM through javascript
and set the focus on the proper dom element?  And what if I wanted to perhaps
display an image in the main Browser window on a "click" event from the dialog?
 I cannot do that presently because when the "click" event comes to me in Java
and I process it, I cannot turnaround and pass a URL back into the main Browser
Window's javascript and add the image to the DOM.  We pass events from
javascript into our java client, where we process events and decide what to do.
Often it is not what would be done in javascript and we cannot completely
rewrite our application in Javascript.  We must be able to freely access
javascript from java.

As far as accessing the DOM of the dialog window, I cannot get the dialog's dom
window through "JSObject domWin = JSObject.getWindow(<applet object>)" because
that would give me the main Browser's window, which does me no good.  Especially
because I cannot get any member of the main Browser's dom window because
"getMember" as in JSObject dlgWin = (JSObject) domWin.getMember("dialog"); does
not currently work as it should.  BTW, in all of my dialog html files, I
immediately assign the dialog's dom window to the main Browser's dom window as a
variable, i.e. window.opener.dialog = window;

So in order to be able get to the dialog's dom window so that I can use
dlgDomWin.call(<method name>, args) in java, I have to pass the dialog's dom
window into java on every event.  So far this works, although it seems like a kluge.

The reason I have to pass it in more than once?  Well, it is not persistent,
i.e. I can make only one 'dlgDomWin.call(<method name>, args)' in java.  If I
try it again without passing in the dialog's dom window, I get an access denied
or some other error message. I do not know why that is either.

I have the same problem with the main Browser's dom window -- I have to call
JSObject domWin = JSObject.getWindow(Applet Object) each time I want to make a
call to a javascript method via 'domWin.call(<method name>, args);'
If somebody can explain to me why I have to keep doing this, I would like to
hear it.  Why aren't the dom Windows persistent?  And how come I need an Applet
(see bug 60018) to get the main browser's dom window, but I can pass in the
dialog's dom window?

Anyway, the main point is that if doing normal, reasonable dynamic updating of
all dom windows in an application through Java via liveconnect is a security
violation, then you need to change your security model.
 

Comment 5

[Jeff Dyer]

Reassigning to Joe

Comment 6

[Xiaobin Lu]

 

*** This bug has been marked as a duplicate of 46518 ***

Comment 7

[Joe Chou]

Xiaobin, would you explain why this is a duplicate of 46518?

Comment 8

[gary.kind]

Yes, I would like a somewhat detailed explanation as to why this bug is a 
duplicate.  I read the other bug and the explanation of the bug there is not 
very good.  Thus I can't tell whether these 2 bugs are duplicates or not? 
Re-opening until a good explanation is placed in this bug. 

Comment 9

[Xiaobin Lu]

 When you click the button, the page will pop up an alert box which is caused by 
calling javascript function call alert. Then an sepreate window will be poped 
out. When you click the button in this dialog box, actually it will call the 
parents' handleEvent javascript function, which first pop out an alert box and 
then call into the applet's handleEvent method. That method will callback into 
javascript which pops out the second dialog box.
  46518 is a bug which is about javascript call java and callback into 
javascript fails. I applied the patch and it works fine now in my merlin build. 
Also, as I mentioned in the mail to you, I do think there is still a bug around 
which is when you close the dialog box, the browser will crash. This has nothing 
to do with liveconnect, but I still recommend you to file a seperate bug about 
this. 

  Please let me know if you satisfy with my explaination.

Comment 10

[Joe Chou]

Currently, the test case works fine on Unix with the recent trunk build and Java
plugin 1.3.1. All the alert boxes and the subwindow came up ok, and there is no
error in Java console.
 
However, on Windows, there are still some problems. First, there was an error in
Java console about class not found. It seemed failed to handle an URL with space
in it (i.e., ".../mozilla bug tests/modalWin_test". If the URL was changed to
something like ".../mozilla_bug_tests/modalWin_test", the error went away.
Second, when trying to invoke the last alert box, calling a JavaScript method
from Java from an alert box, the call failed, and the last alert box did not
show up. The problem seemed to be a regression, since the same function worked
earlier on Windows. When tested with JRE 1.4 (the beta version) on Windows, the
problem seemed to be fixed. Per Xiaobin, that's due to the preliminary fix of
46518, which will be available in the next release 1.4 of JRE. However, the
testing in 1.4 seemed unstable at the present time, which showed some other
problems. 
It seems to make sense to leave this bug open at this point, till a complete fix
is found for this bug on Windows.

Comment 11

[shrirang khanzode]

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

Comment 12

[Joe Chou]

Tested with current build on WinNT with JRE 1.4 bate 3, the test case worked.
Mark WORKSFORME.

Comment 13

[Patty Mac]

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

Comment 14

[Matthias Versen [:Matti]]

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

Comment 15

[dsirnapalli]

-- Verified the above test case on current trunk build on WinXP with
JRE1.4.1_02. Its working fine. Marking verified.