29053 - GetElementById on document.writte()n content onload fails

Status: VERIFIED WONTFIX

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

Description

[Robert Ginda]

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.

Comment 1

[Chris Waterson]

vidur: do you know anything about getElementById() with document.write() not 
working?

Comment 2

[Chris Waterson]

more love.

Comment 3

[Robert Ginda]

This Just Works now.  Maybe I need to adjust my medication.
Marking WORKSFORME.

Comment 4

[Robert Ginda]

Reopening, change writeStyle=false to writeStyle=true (in the testcase attached
to bug 29052) to see the failure.

Comment 5

[Robert Ginda]

Reassign to component owner.

Comment 6

[Johnny Stenback (:jst)]

This seems to have been fixed, marking FIXED.

Comment 7

[Robert Ginda]

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'

Comment 8

[Johnny Stenback (:jst)]

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.

Comment 9

[Wolfgang Schwarz]

isn't this Bug 63423 as well?

Comment 10

[Brendan Eich [:brendan]]

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

Comment 11

[Johnny Stenback (:jst)]

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?

Comment 12

[Brendan Eich [:brendan]]

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

Comment 13

[Robert Ginda]

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*.

Comment 14

[Brendan Eich [:brendan]]

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[0].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

Comment 15

[Johnny Stenback (:jst)]

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.

Comment 16

[Prashant Desale]

WONTFIX

Comment 17

[Boris Zbarsky [:bzbarsky]]

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