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 <http://xmlterm.com/dyn_iframe.html> Loading the above URL in Mozilla results in the following error message on the console: JavaScript Error: TypeError: ifr.document has no properties URL: http://xmlterm.com/dyn_iframe.html 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!
Created attachment 3840 [details] Document to reproduce IFRAME error
Reassigning to Eric.
Accepting bug and setting milestone to M19.
Bumping up milestone and severity based on number of votes this bug has received.
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 dom/html4
Marking nsbeta3-
Moving bug marked nsbeta3- to Future milestone.
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?
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. Gerv
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
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. thanks,
*** 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 SCRIPT SRC). The industry standard ad tag has the following form: <IFRAME SRC=> <SCRIPT SRC=> </SCRIPT> <NOSCRIPT> </NOSCRIPT> </IFRAME> 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 Mozzila...talk 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. beonex.com) 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.
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
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
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.
Doesn't look like this is getting fixed before the freeze tonight. Pushing out a milestone. Please correct if I'm mistaken.
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 prefrences. Good luck to all the developers and best wishes for a succesful Mozilla. Signing off. Bora
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.
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
*** 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 browser?
This bug is misassigned -- pollmann doesn't hack on Mozilla any longer. jst, are you willing to take this? /be
I'll take this for now, not sure when I'll get to it tho...
Pushing to mozilla0.9.7
Maybe to help pinpoint this problem (or add to the description detail)...it 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 development.
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) [nsIDOMNSHTMLDocument.open]" 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
http://www.w3.org/TR/2001/WD-DOM-Level-2-HTML-20011025/html.html#ID-50708718 I don't see any document member here.
It's because they're accessing it as window.frames which is a window object. And window objects do have a document member.
Created attachment 60082 [details] Dynamically created nested iframes have no document object
Dynamically created nested iframes are again empty shells. The problem we had with this bug remains for the nested iframes. danm@netscape.com may have a easy fix for this since he fixed the head of the problem.
*** Bug 35250 has been marked as a duplicate of this bug. ***
Pushing out to mozilla1.1.
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. /be
Created attachment 82920 [details] Severe Problem with dynamic iframe
>>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?
Comment on attachment 82920 [details] Severe Problem with dynamic iframe This is no longer a problem with latest builds
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 http://home.planetinternet.be/~pbajoit/Genealogie/genealogie.htm 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: <body> <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 <IFRAME FRAMEBORDER="0" MARGINWIDTH="1" MARGINHEIGHT="1" WIDTH="100%" HEIGHT="150" ID="fiche" SRC="blank.htm"> Your browser does not support IFRAME ! </IFRAME> <IFRAME FRAMEBORDER="0" MARGINWIDTH="1" MARGINHEIGHT="1" WIDTH="100%" HEIGHT="100" ID="ascendance" SRC="blank.htm"> Your browser does not support IFRAME ! </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
http://home.planetinternet.be/~pbajoit/Genealogie/genealogie.htm 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.
or
