92912 - javascript will not execute in dynamically created iframe

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Geraint]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2+) Gecko/20010730
BuildID:    2001073008

Open the URL http://www.copyn.plus.com/mozTest16.html
This page contains two iframes - one part of the html and the other added
dynamically using addElement.

Both IFrames should be turned black by the javascript within the iframe - this
happens for the 'static' iframe but does not for the dynamically added iframe. 
The javascript in the dynamic iframe is not executed at all.

This was not a problem with Netscape 6 or Mozilla 0.9.1.



Reproducible: Always
Steps to Reproduce:
1.Open http://www.copyn.plus.com/mozTest16.html



Actual Results:  The right iframe remains red but left iframe is turned black

Expected Results:  Both iframes should be turned black by the javascript within
the iframe.

Have also tested this on build 2001073017 under windows NT 4.0 workstation with
the same error occuring.

This is a critical requirement of our company's web application which we have
consistently strived to ensure works with Netscape 6/Mozilla in addition to MSIE 5+.

Comment 1

[David Illsley]

linked to bug 90533 ??

Comment 2

[Geraint]

This bug does not rely on onLoad being fired for the javascript to fail.

open http://www.copyn.plus.com/mozTest18.html for illustration without setting
onLoad.

Comment 3

[Boris Zbarsky [:bzbarsky]]

I see this with linux build 2001-07-30-06

Over to DOM Core.

Comment 4

[Johnny Stenback (:jst)]

Attachment: Don't bother doing security checks while the context is being initialized

Comment 5

[Johnny Stenback (:jst)]

The reason this wasn't working was that the security checks that are done while
the context and global object are being initialized were failing since the
script global object didn't know about the global JSObject this early on so the
security manager was being passed a null JSObject. In normal cases this works
since the security manager is not able to get a principal from the script global
object, but in this case it gets the principal of the parent and tries to do a
same origin check, which fails since the JSObject that's passed in is null.

The fix I attached is to not bother doing security checks until the context is
fully initialized.

r & sr = anyone?

Comment 6

[Johnny Stenback (:jst)]

Nisheeth sez r=nisheeth

Comment 7

[Johnny Stenback (:jst)]

*** Bug 94223 has been marked as a duplicate of this bug. ***

Comment 8

[Brendan Eich [:brendan]]

So long as no web JS could sneak in and run (nesting on the main thread) under
InitContext....  sr=[e-mail].

/be

Comment 9

[Johnny Stenback (:jst)]

Mitchell, here's the security check patch we were talking about earlier today,
see last attachment.

Comment 10

[Johnny Stenback (:jst)]

Fix checked in.

Comment 11

[Mitchell Stoltz (not reading bugmail)]

What brendan said...do you think that's a possibility?

Otherwise, this looks OK provided that IsContextInitialized() always returns the
correct value. Is there any way the result of IsContextInitialized could be
messed up?

Comment 12

[Johnny Stenback (:jst)]

I don't see how that could possibly happen, if that happens the context
initialization fails and no scipts should run at all on that context. We could
bullet proof the code in nsJSContext::InitContext() to always set the
mIsInitialized to PR_TRUE even if initializing the context fails, let me know if
that would make you sleep better at night and I'll do that :-)

Comment 13

[Sivakiran Tummala]

verified 2001-09-12-05