Closed
Bug 22681
Opened 25 years ago
Closed 21 years ago
Unable to alter content of dynamically created IFRAMEs
Categories
(Core :: Layout: Images, Video, and HTML Frames, defect, P3)
Core
Layout: Images, Video, and HTML Frames
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: svn, Assigned: jst)
References
()
Details
(Keywords: relnote, Whiteboard: [Hixie-P2] [nsbeta3-] relnote-devel)
Attachments
(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
<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!
Reporter | ||
Comment 1•25 years ago
|
||
Updated•25 years ago
|
Assignee: karnaze → pollmann
Comment 2•25 years ago
|
||
Reassigning to Eric.
Comment 3•25 years ago
|
||
Accepting bug and setting milestone to M19.
Status: NEW → ASSIGNED
Target Milestone: --- → M19
Comment 4•25 years ago
|
||
Bumping up milestone and severity based on number of votes this bug has
received.
Severity: normal → major
Target Milestone: M19 → M17
Comment 5•25 years ago
|
||
I recieved the same error message using the test page on Windows 98 with build
id 2000062108.
Comment 6•25 years ago
|
||
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.
Comment 9•25 years ago
|
||
Nominating for beta3 based on number of votes and feature completeness for
dom/html4
Keywords: correctness,
nsbeta3
Comment 11•24 years ago
|
||
Moving bug marked nsbeta3- to Future milestone.
Target Milestone: M17 → Future
Comment 12•24 years ago
|
||
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?
Updated•24 years ago
|
Whiteboard: [nsbeta3-] → [nsbeta3-] relnote-devel
Comment 13•24 years ago
|
||
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
Keywords: mozilla0.9
Comment 14•24 years ago
|
||
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...
Comment 16•24 years ago
|
||
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,
Comment 17•24 years ago
|
||
*** Bug 51281 has been marked as a duplicate of this bug. ***
Comment 18•24 years ago
|
||
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.
Comment 19•24 years ago
|
||
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.
Comment 20•24 years ago
|
||
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
Comment 21•24 years ago
|
||
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.
Comment 22•24 years ago
|
||
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.
Comment 23•24 years ago
|
||
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?
Comment 24•24 years ago
|
||
Setting milestone to mozilla0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Comment 25•24 years ago
|
||
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.
Comment 27•24 years ago
|
||
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.
Updated•24 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.3
Comment 28•24 years ago
|
||
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
Comment 29•24 years ago
|
||
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...
Comment 30•24 years ago
|
||
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!
Comment 31•24 years ago
|
||
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.
Comment 32•24 years ago
|
||
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
Comment 33•24 years ago
|
||
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.
Updated•24 years ago
|
Whiteboard: [nsbeta3-] relnote-devel → [Hixie-P2] [nsbeta3-] relnote-devel
Comment 34•23 years ago
|
||
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
Comment 35•23 years ago
|
||
*** Bug 61468 has been marked as a duplicate of this bug. ***
Comment 36•23 years ago
|
||
*** Bug 88291 has been marked as a duplicate of this bug. ***
Comment 37•23 years ago
|
||
*** Bug 92557 has been marked as a duplicate of this bug. ***
Comment 38•23 years ago
|
||
*** Bug 100616 has been marked as a duplicate of this bug. ***
Comment 39•23 years ago
|
||
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?
Comment 40•23 years ago
|
||
This bug is misassigned -- pollmann doesn't hack on Mozilla any longer. jst,
are you willing to take this?
/be
Assignee | ||
Comment 41•23 years ago
|
||
I'll take this for now, not sure when I'll get to it tho...
Assignee: pollmann → jst
Status: ASSIGNED → NEW
OS: Linux → All
Hardware: PC → All
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Assignee | ||
Comment 42•23 years ago
|
||
Pushing to mozilla0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Depends on: 88229
Comment 43•23 years ago
|
||
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.
Comment 44•23 years ago
|
||
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.
Comment 46•23 years ago
|
||
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.)
Comment 47•23 years ago
|
||
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?
Comment 48•23 years ago
|
||
WOW, it is really working. I used the latest build.
Excellent Job Dan,
Comment 49•23 years ago
|
||
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.
Assignee | ||
Comment 51•23 years ago
|
||
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.
Comment 52•23 years ago
|
||
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
Comment 53•23 years ago
|
||
http://www.w3.org/TR/2001/WD-DOM-Level-2-HTML-20011025/html.html#ID-50708718
I don't see any document member here.
Comment 54•23 years ago
|
||
It's because they're accessing it as window.frames which is a window object. And
window objects do have a document member.
Comment 55•23 years ago
|
||
Comment 56•23 years ago
|
||
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.
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Comment 57•23 years ago
|
||
*** Bug 35250 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 58•23 years ago
|
||
Pushing out to mozilla1.1.
Target Milestone: mozilla0.9.9 → mozilla1.1
Updated•23 years ago
|
Keywords: mozilla1.0+
Comment 59•23 years ago
|
||
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.
Comment 60•23 years ago
|
||
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
Comment 61•23 years ago
|
||
danm wasn't cc'ed, but someone uttered his name reverently. Cc'ing him.
/be
Updated•23 years ago
|
Keywords: mozilla1.0+ → mozilla1.0-
Comment 62•23 years ago
|
||
Comment 63•23 years ago
|
||
>>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'.
Comment 64•23 years ago
|
||
Sorry for the spam and please ignore the previous additions I made. It is now
working???? I will make further tests.
Sorry again
Comment 65•23 years ago
|
||
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
Comment 66•23 years ago
|
||
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?
Assignee | ||
Updated•22 years ago
|
Target Milestone: mozilla1.1alpha → ---
Comment 67•22 years ago
|
||
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
Comment 68•22 years ago
|
||
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?
Comment 69•21 years ago
|
||
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.
Comment 70•21 years ago
|
||
Philippe, those iframes in the url are not dynamically created.
Comment 71•21 years ago
|
||
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.
Comment 72•21 years ago
|
||
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
![]() |
||
Comment 73•21 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Updated•6 years ago
|
Product: Core → Core Graveyard
Updated•6 years ago
|
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.
Description
•