Closed Bug 22681 Opened 25 years ago Closed 21 years ago

Unable to alter content of dynamically created IFRAMEs


(Core :: Layout: Images, Video, and HTML Frames, defect, P3)






(Reporter: svn, Assigned: jst)




(Keywords: relnote, Whiteboard: [Hixie-P2] [nsbeta3-] relnote-devel)


(2 files, 1 obsolete file)

IFRAME elements created dynamically using DOM do not behave properly

Platforms: Linux (RedHat6.1), Solaris 2.6

Mozilla releases: M12, Dec 26 daily build

Possibly related to bug 16385

I have been trying to use dynamically created IFRAME elements for my terminal
emulator component (the code is in mozilla/extensions/xmlterm). What I'm
trying to do is to create IFRAMEs using the CreateElement method of a
DOMDocument that has already been loaded, and then insert content into the
IFRAMEs dynamically. When I test my content insertion code using static
IFRAMEs, i.e., IFRAMEs embedded in a test HTML document, everything works
fine. However, when I try to create IFRAMEs on the fly, things don't work
properly. I have tried two approaches, both of which fail:

I. (Easily reproducible)
   Load about:blank initially in the IFRAME and then try to write to the
   IFRAME using its window.document.write() method. This fails for
   dynamically created IFRAMEs because the window.document object is null.
   I have created a simple HTML file with Javascript that reproduces this
   error. It is available in the URL
   Loading the above URL in Mozilla results in the following error
   message on the console:
     JavaScript Error: TypeError: ifr.document has no properties
     LineNo: 27

   Interestingly, this error does not occur in older milestone releases
   of Mozilla, such as M9 or earlier.

II. (Not easily reproducible)
   The second approach is more involved and uses an InputStreamChannel
   to modify the IFRAME's content dynamically (the code is in
   mozilla/extensions/xmlterm/base/mozXMLTermStream.cpp). It would not be
   easy for someone else to reproduce the errors that I encounter in trying
   to use this approach, but basically what happens is that I dont' get any
   explicit error message. The dynamic content that I insert appears to be
   rendered, because I keep track of the page size, but is not visible at all.
   All I get is a blank IFRAME in the end, but of the right width and height!
Assignee: karnaze → pollmann
Reassigning to Eric.
Accepting bug and setting milestone to M19.
Target Milestone: --- → M19
Bumping up milestone and severity based on number of votes this bug has
Severity: normal → major
Target Milestone: M19 → M17
I recieved the same error message using the test page on Windows 98 with build 
id 2000062108.
The problem in this case seems to be that GlobalWindowImpl::SetNewDocument is 
called *after* GetDocument.  This means that the iframe's document is loading 
after we're trying to access it here.  Setting the new document looks to be an 
asynchronous operation, possibly on another (netlib) thread.

One nifty thing to do here might be to ensure that a document always exists for 
a window, and not wait until we start getting bits off the network (or in this 
case from the file stream for about:blank).  This might also take care of bug 
5569 and also be a cleaner way to handle bug 35986.

CC'ing Adam
The same example is returning the document object of the dynamicaly created 
iframe 'null' even if you set the SRC attribute to point a particular html page.
Bug is not just for SRC='about:blank'. For the future fix, I recommend the 
testing of the accesiblity of document objects for the nested iframes as well.

Hope to see this bug fixed in M17.
Another related misbehaviour for dynamically created iframes; It is not just 
the document object is being set empty. If you specify a target src html and 
put some javascript functions into it. Accessing to those function thru a 
Dynamically created iframe is not possible. However, if you create an frame 
statically in the body tag using the same src html, then it is all fine.

dynamically created iframes are missing everthing except styles and attributes.
Nominating for beta3 based on number of votes and feature completeness for
Keywords: correctness, nsbeta3
Marking nsbeta3-
Keywords: relnote
Whiteboard: [nsbeta3-]
Moving bug marked nsbeta3- to Future milestone.
Target Milestone: M17 → Future
May I ask why this annoying bug was tagged future suddenly? it has been 5 
milestones already since then. On the other hand, all the iframe bugs are 
tagged future in bugzilla? has the person responsible for iframes quit working 
with you?
Whiteboard: [nsbeta3-] → [nsbeta3-] relnote-devel
Nominating for mozilla0.9. Pollmann - any chance of revisiting this? It's
blocking the development of a significant feature in XMLTerm, which is a very
cool XML-aware xterm application.

Keywords: mozilla0.9
It has been almost a year since this bug was reported and nothing has happened. 
This is not acceptable. Instead of fixing DOM level 1 bugs you are extending 
Mozilla with XUL and XNL. Don't get me wrong, I like XUL and XBL, but I think 
DOM should have a higher priority than proprietary extensions.

I think this bug should have a higher priority than 3...

Set milestone to mozilla0.9
Target Milestone: Future → mozilla0.9
I was wondering if this bug will be fixed as targeted on mozilla0.9? The reason 
I am asking it has been tagged 'future' couple of times back and halted our 
development which needs this feature. 

*** Bug 51281 has been marked as a duplicate of this bug. ***
This bug has serious ramifications for the internet ad industry as a whole.  
There are literally 1000s of AdMasters that traffic ads using document.write 
in some part of the ad definition every day.  We have long waited for Mozilla to 
support IFRAMEs to simplify RichMedia ad delivery (consider what it takes to use 

The industry standard ad tag has the following form:


Since there are literally Gpages with these tags (After all ad delivery is 
probably the single biggest financial driver on the internet), everyone is now 
faced with the prospect of users hitting their pages with Mozilla and having ads 
break.  We can't stop Mozilla from using IFRAME and there is no way we are going 
to stop using IFRAME, which leaves us with the only option: every one of these 
ads needs to make an exception and deliver a gif or something in the case of about wasted man hours.

This is not a P3 bug.  It is a P1 with the entire internet economy behind it.
As this bug has major implications for the Internet advertising industry I think
it would be great to see the likes of doubleclick contribute resources to fix
this. If you've got suitable coders inhouse then you could assign coders to
fixing this, if you haven't then you could contract out the work or get some
company that offers this service (e.g. to do so.

It'd also be good PR for doubleclick saying that they're not particularly
popular in some circles for their ad tracking (never bothers me tho). It would
also guarantee that this would be fixed. That's the great thing about open
source if you want something fixed that badly and you've got the resources to
fix it then you can.
Nominating for nsbeta1 consideration. Want dynamically generated content to 
work the same as static content. Plus, we have evidence of actual customer 
impact. As noted by previous poster, would be great if DoubleClick et al would 
contribute an engineer to work on this--or at least QA resources to help verify 
if they can't contribute an engineer.
Keywords: nsbeta1
I do not think you will have any problem on QA side. There will be many people
(including me) testing dynamic iframe's functionality. On the other hand, as I 
see you are still looking for engineers to help on this; I do not believe 
anybody could catch up with Mozilla source tree that quick. Obviously, this bug 
is not going to make the mozilla0.9 seeing the nightlies so far. If Eric is too 
busy or overburdened, may be it is likely that you should ask another engineer 
familiar with mozilla source tree to take this over. My personal observation is 
that you shouldnt extend mozilla with features full of bugs just to say that it 
has those features. It is ,to me, waste of valuable man and brain power. 
Mozilla team should perfect the core DOM and layout first then fixing those 
extensions up will not be that painful.
The problem appears to be that the IFRAME is not added to the list of children 
of the docshell until the next reflow occurs. In the meantime, the javascript 
tries and fails to find it from the collection.

If we could force an immediate reflow when child frames are appended it should 
sort this problem out.
Not that I have the first clue about this or anything, but...

That doesn't strike me as an optimal solution. A reflow is an expensive
operation, and if js is going to be modifying the content of the iframe then
another reflow will have to be done afterwards too. Performing a reflow just to
add a child to the docshell sounds like a waste of processing time - how hard
would it be to add the iframe into the docshell at creation time rather than at
reflow time?
Setting milestone to mozilla0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Well! isnt there a quick nasty fix for this bug. I wouldnt mind reflowing 
either. Something working ,until you guys get it all redone, would really help 
people developing on mozilla. At least, people who needs dynamic Iframes could 
make their development parallel. And we can at least say "here we go our 
product is also working on all mighty mozilla but we are still waiting for some 
bugs to be fixed". Cant you put a very nasty HACK/WORKAROUND for this bug to be 
working for now? 

just a thought.
QA Contact update
QA Contact: petersen → amar
Just wanted to add that if a frame is added using DOM with display: none then 
the frame is not added to the frames collection.
Target Milestone: mozilla0.9.1 → mozilla0.9.3
Doesn't look like this is getting fixed before the freeze tonight.
Pushing out a milestone.  Please correct if I'm mistaken.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Here's the activity log of target_milestone changes:
2000-04-10 15:28:56 ... M19          
2000-04-10 15:33:39 ... M17          
2000-08-15 18:55:59 ... Future       
2000-12-20 14:48:04 ... mozilla0.9   
2001-03-01 15:32:37 ... mozilla0.9.1 
2001-05-15 12:16:56 ... mozilla0.9.3 
2001-07-24 14:54:43 ... mozilla0.9.4

Maybe the use of target_milestone values should be rethought...
I believe it is time to tag this bug as 'FUTURE'. The fact that it has 26 votes 
on it shouldnt make you push this bug incrementally to the next milestone. That 
aint making any phychological relief, believe me! 

Yes, this is a major bug.

Since Mozilla doesn't allow DIV's to be positioned over IFRAMEs (Bug 91516), 
positioning an IFRAME over an IFRAME is the only workaround left.

This bug prevents to use such a workaround in a clean way.
The display:none problem that Erik mentioned makes it even worse.
(Erik, could you file a new one for that?)

We use such functionality (in IE5+) for a menuing system that overlays the page 
contents in various DHTML database frontends.

Apart from that, it's a pretty blatant DOM1 incompatibility.
This is futile! We have just dropped mozilla support, and do not think of 
supporting it in future either because of this bug! I would like my account 
deleted from bugzilla; I looked around for the link to delete my account, but 
there is none. I think, I will just turn off all the email check boxes from 

Good luck to all the developers and best wishes for a succesful Mozilla.

Signing off.
You are not the only one who has dropped support for Mozilla. However once 
Mozilla gets to 1.0 I might actually reconsider trying to get some simple 
DHTML/DOM applications to work. I've still not totally given up and I think 
that the current state of the DOM in Mozilla is a good start. I just hope that 
AOL realize that it is just a start and that a lot of development on the DOM 
front is still needed.
Whiteboard: [nsbeta3-] relnote-devel → [Hixie-P2] [nsbeta3-] relnote-devel
eric is no longer around.  
we need some more time to figure out who can own this bug.
anybody have ideas?

unlikley this will make 0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
*** Bug 61468 has been marked as a duplicate of this bug. ***
*** Bug 88291 has been marked as a duplicate of this bug. ***
*** Bug 92557 has been marked as a duplicate of this bug. ***
*** Bug 100616 has been marked as a duplicate of this bug. ***
This bug is having a critical impact on my place of business. We have clients 
wanting to use Netscape 6.1 (build 20010726 of Mozilla) because "their computer 
crahsed and they thought why not get the newest version of Netscape".  We 
create framed page dynamically and write to the left frame and get the right 
frame back from the server.  It's so wonderful that we use it for most of our 
applications on the web.  Now we have not choice but to force them to use IE 
5.0 or Netscape 4.7x.  It looks like this hasn't been touched in a couple of 
months.  Any chance it's being worked on?  Also...wouldn't Netscape want to 
cough up the resources to fix this since it's in their latest and greatest 
This bug is misassigned -- pollmann doesn't hack on Mozilla any longer.  jst,
are you willing to take this?

I'll take this for now, not sure when I'll get to it tho...
Assignee: pollmann → jst
OS: Linux → All
Hardware: PC → All
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Blocks: 104166
Blocks: 105405
Pushing to mozilla0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Maybe to help pinpoint this problem (or add to the description detail) does
seem to be possible to write content to a dynamically-created iframe, BUT ONLY
with a separate event.  That is, if I have a separate button with an onClick
event that calls a function to populate content to the dynamically-created
iframes, it will work.  However, if I call the function from within another
function, it fails to write to the iframes.  
Also, I'd just like to add that the team I am on is developing an application
for a 45,000 employee company that will be used world-wide by employees and
vendors.  We NEED this functionality, and are still deciding whether or not to
support both IE and Netscape in our first release.  While we do have a clumsy
work-around for now, we would like to know whether this bug is expected to be
fixed in the next NN release, as this will determine the direction of our
A fix is coming in bug 88229, it's very close.
Test case (I) (in this bug's first comment) works now. (Well, except there's a 
bug in the test case source you wouldn't have noticed until now. Hee hee.)
I was excited for a second! Is the fix checked in to 0.9.6? It is still not 
working(I, of course, corrected the code and run)? same error 'ifr has no 
properties' using mozilla build ID 2001112009...Damn are you sure the 
attachment is working now?
WOW, it is really working. I used the latest build. 

Excellent Job Dan,

Anyone know which release of Netscape this might show up in?
"The next one". No-one will be allowed to tell you when that will be, even if
they knew.
Yes, this should be in the next major Netscape release (i.e. probably not in
Netscape 6.2.x), as I'm sure guessed, I can't give out a version number or a
release date.
I have created some nested iframes dynamically inside a dynamically created 
iframe. But, I can not access to the document of nested frames. Here are the 
exceptions thrown.

Error: [Exception... "Component returned failure code: 0x80004005 
(NS_ERROR_FAILURE) [nsIWebProgress.DOMWindow]"  nsresult: "0x80004005 
(NS_ERROR_FAILURE)"  location: "JS frame :: 
chrome://navigator/content/nsBrowserStatusHandler.js :: anonymous :: line 202"  
data: no]
Source File: chrome://navigator/content/nsBrowserStatusHandler.js
Line: 202

Error: uncaught exception: [Exception... "Component returned failure code: 
0x80004003 (NS_ERROR_INVALID_POINTER) []"  
nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" ]

Error: [Exception... "Component returned failure code: 0x80004005 
(NS_ERROR_FAILURE) [nsIWebProgress.DOMWindow]"  nsresult: "0x80004005 
(NS_ERROR_FAILURE)"  location: "JS frame :: 
chrome://navigator/content/nsBrowserStatusHandler.js :: anonymous :: line 231"  
data: no]
Source File: chrome://navigator/content/nsBrowserStatusHandler.js
Line: 231
It's because they're accessing it as window.frames which is a window object. And
window objects do have a document member.
Dynamically created nested iframes are again empty shells. The problem we had 
with this bug remains for the nested iframes. may have a easy 
fix for this since he fixed the head of the problem.
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → mozilla0.9.9
*** Bug 35250 has been marked as a duplicate of this bug. ***
Pushing out to mozilla1.1.
Target Milestone: mozilla0.9.9 → mozilla1.1
Keywords: mozilla1.0+
Doesn't this mean that Moz1.0 will NOT be DOM1 compliant?

IMHO this means that document.createElement("IFRAME") does not work correctly 
and therefore DOM1 is not supported. Therefore 
document.implementation.hasFeature("HTML", "1.0") should not return true like 
it currently does.
Erik, the original bug is fixed. Only the edge case of nested iframes will show
this bug. And in any case, I'd be the happiest man on earth if this bug was the
very last issue we had to fix for DOM1 compliance. That should definitely not be
an argument to require that this bug be fixed for 1.0. 
Following your logic, hasFeature() would be more than useless because no browser
is entirely DOM1 compliant, so all the browsers should return false.
We'll review the hasFeature() implementation for 1.0 anyway, you can make
yourself heard on that issue in bug 30534
danm wasn't cc'ed, but someone uttered his name reverently.  Cc'ing him.

Keywords: mozilla1.0+mozilla1.0-
Attached file Severe Problem with dynamic iframe (obsolete) —
>>the original bug is fixed. Only the edge case of nested iframes will show
>>this bug.

Unfortunately, this is a comment made without proper testing of the presumed
'FIXED' portion of the bug. Although we can create a dynamic Iframe and set the
SRC successfully, we are unable to add not only other Iframes(nested iframes)
but any other elements as well. Please check the new attachment. The Dynamicly
created  Iframes are dead zombies; however, we can reach to their document
object successfully. There must be a little something left behind for 'the
original bug'.
Sorry for the spam and please ignore the previous additions I made. It is now
working???? I will make further tests.

Sorry again
SPAM - SPAM sorry sorry. After loading the attachment it works for the first
time then hit the refresh button, then the 'hear you' text will disappear.

thanks and sorry
I am not having problems on refresh.

However, there is some other strange behaviour. Visiting attachment id 82920
("Severe Problem with dynamic iframe") seems to screw up the history, listing
itself as both the current page and the previously viewed page (as shown under
the Go menu or the context menu on the Back button).

The problem of "Hear you" not being written again IS experienced when going back
to a previously viewed page (like this one) and then revisiting the attachment
by going forward in the history.

[Note: IANAMH (I Am Not A Mozilla Hacker), so the following is just a bunch of
potentially way off-base theory]
Visiting pages using one's history displays cached versions of the page usually,
so I suspect the problem here is really about how/whether Mozilla caches
dynamically modified versions of a page. Is it supposed to be only caching the
initial, static stuff and reexecuting any dynamic javascript code when viewed
again, using the cached version as a base?
Target Milestone: mozilla1.1alpha → ---
Comment on attachment 82920 [details]
Severe Problem with dynamic iframe

This is no longer a problem with latest builds
Attachment #82920 - Attachment is obsolete: true
Is this bug stil reproducable? The attached testcases seems to have some js
errors? The testcases in the dupes works fine. Build 2003032204.

Can anyone verify?
Still exist in FireBird 0.6.1 (20030827) or Mozilla 1.3b but not in FireBird 0.5.
Example at
where 6 IFRAMEs exist, the first one and the last one are good, the 2nd to the
5th are empty.
Philippe, those iframes in the url are not dynamically created.
OK, practically there are 6 IFRAMEs (not dynamically created), the content of
all is dynamically generated by using JavaScript:

I assign a source to an IFRAME with ID "ascendance":
document.getElementById("ascendance").src = "ascendance.html?id=" + n;

In "ascendance.html" I build the HTML:
<script language="javascript" type="text/javascript">
document.writeln("<table cellspacing='1' width='100%'>");

The problem is different and amazing between Phoenix 0.5 and Firebird 0.6: in
the HTML

HEIGHT="150" ID="fiche" SRC="blank.htm">
Your browser does not support IFRAME !
HEIGHT="100" ID="ascendance" SRC="blank.htm">
Your browser does not support IFRAME !

the IFRAMEs are placed on top of each other, only the first one being visible.
Simply adding a <BR> between the IFRAMEs forces them to have a different location.

I understand it is not a bug about 'Unable to alter content of dynamically
created IFRAMEs' and I should check W3C standards because to qualify this
behavior of bug or feature.
Sounds like a regression.  Wonder if dbaron or bz know of it already.  Can
someone narrow it down in a Mozilla (SeaMonkey) milestone, or even nightly,
build?  The interval between Phoenix 0.5 and Firebird 0.6 was quite long.

/be renders 
identically in IE 5.5 and Mozilla 1.5b on Windows 98 over here.

In any case, as comment 71 says, that's not this bug.

As for this bug... the first testcase posted here works in current builds.  The 
second testcase is fundamentally flawed, since it assumes that document loads 
are synchronous -- they are not.

The third testcase also works with current builds.

I'm marking this bug worksforme.  Philippe, if you can reproduce your problem 
with a 1.5b SeaMonkey build or equivalent Firebird nightly, please file a bug 
on it and cc me; that will let us work on that problem without carrying around 
the baggage of 70-some comments on a totally different topic.
Closed: 21 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.