If content is written to an iframe in a page's onload handler, and that content contains a stylesheet, a getelementbyid call looking for an ID written to the iframe will fail (ie, return null.) Steps to reproduce: 1) grab the testcase from bug 29052, save as directed in bug 29052. 2) start mozilla 3) load docwrite.html (without ?onload) 4) click, in order, open, write, close, getelementbyid. Mozilla will display: -*- output is 'null' in the console. If you edit docwrite.html to not write a stylesheet (as explained in bug 29052) and follow the steps described above, Mozilla will display: -*- output is '[object HTMLDivElement]' in the colsole.
vidur: do you know anything about getElementById() with document.write() not working?
This Just Works now. Maybe I need to adjust my medication. Marking WORKSFORME.
Reopening, change writeStyle=false to writeStyle=true (in the testcase attached to bug 29052) to see the failure.
Reassign to component owner.
This seems to have been fixed, marking FIXED.
Sorry, my steps to reproduce are buggy. Load the testcase with ?onload, and writeStyle set to true, and you'll still get -*- output is 'null'
This bug has been marked "future" because the original netscape engineer workingon this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
isn't this Bug 63423 as well?
Wolfgang: good catch. jst: can we dup this bug against bug 63423 in order to capture that bug's more detailed analysis? I think we have to flush the parser's buffer to make documente.write and getElement* cohere. /be
This is actually different than bug 63423, here an external css file load is initiated by data that is document.write()'n so the parser is blocked until the css file is done loading, and that won't be util the script that does the document.write() and document.getElementById() is done (it can't happen until the main thread rewinds back to the event loop). To fix this we'd haveto either not block the parser while css file loads initiated from parsing document.write()'n data, or we'd need to some event loop fun to block the main thread while the css file loads so that the document.write()'n data is parsed before the document.write() call returns. Ideas?
Ah so -- and I don't believe this should be fixed. Rather, the DoLocate() call in the testcase should be from kontent.onload. There is no guarantee that when writing HTML to another frame or window, the layout of that window's new content won't "block" somehow (even MozillaClassic blocked, e.g., on images without height= or width=). rginda, can you use kontent.onload? It seems like you should be able to, as you are generating its entire document. If kontent.onload runs too late, then you could generate an inline script in that document that comes after the tag of the element you want to get by id. Then you may well need the fix for bug 63423! /be
Mmm, I worked around this a while ago. I think kontent.onload worked for a while, then broke, and I switched to a setTimeout-based idea. I'd have to try again to be sure. fwiw, It seems odd (strictly from a DOM user's standpoint) that something that has just been document.write()'n isn't immediately getElementById()-able. Whether or not the css (or image data) has actually loaded, an otherwise reasonable person might expect the element to a least *exist*.
While it might be nicer for document.writers if all layout engines built some kind of "first-line" content model so that getElementById could "succeed" (but maybe not, if an attempt to get an element attribute then fails because of unmaskable non-blocking i/o or other continuation-style programming that usually hides under the hood), it has never been implementable in MozillaClassic, and is not easily done in Gecko. Ever since 2.0, when JS and document.write debuted, document.write("<form><input name=t1><\/form>") followed by a reference to document.forms.t1 would work, while document.write("<img src=foo.gif><form><input name=t1><\/form>") would not because the img lacks height and width. I added event handlers sufficient to cope with this "asynchrony", and here we are. /be
Since there's no easy way to fix this and there's no really strong argument for doing so I'm marking this as WONTFIX.
*** Bug 165053 has been marked as a duplicate of this bug. ***