165053 - getElementById() fails on generated content [JS console says: document.getElementById("a_generated_element") has no properties]

Status: RESOLVED DUPLICATE of bug 29053

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

Description

[Mike Holderness]

[whatWin.document.getElementById("sizer") has no properties]
says Mozilla, when - and as far as I can tell only when - "sizer"
is the ID of an object in a page of HTML generated by JS. 

Background: I want to present JS output tables in popup windows. 
It'd be nice to size these neatly to the table which is of course
of unpredictable length. So I'm playing around trying to find a 
cross-platform solution to this quirky problem. 

Expected behaviour: whatWin.document.getElementById("sizer").style.height
returns "undefined", leaving me merely frustrated. 

Actual behaviour: as above. 

Builds: 1.0 RC 1 (Win NT4); also 1.0 (Win98); 1.1 RC 1 (Win 98)

Comment 1

[Phil Schwartau]

Browser, not engine ---> DOM Level 0.

Confirming bug using Mozilla trunk binary 20020823xx WinNT.
This looks like the same issue as in these reports:


bug 164975
"script execution stops accessing new window property; timing related?"
bug 142555 
"early cross window javascript function calls fail"
bug 159424
"Objects cannot be passed between windows. Scope for seems to be changed."
bug 52238
"window handle returned by open/openDialog does not provide
a handle to a valid JS context"

Comment 2

[Phil Schwartau]

The reason I say that: the JS at this site does 

        whatWin=window.open("", etc.)

and then tries to access properties of |whatWin|. That is the 
same issue as in the above bugs, I believe -

Comment 3

[Mike Holderness]

Having read the bug reports that Phil references, I 
should mention that timing problems did occur to me. 

I still saw the problem even with the additional line 

   for (i=0; i<1000000; i++) {foo="waste time"}

just after the whatWin.document.close() in the 
(rather complicated) full case. 

Comment 4

[Mike Holderness]

Ooops. (Something like) that *was* in the test case. I'll shut up now.

Comment 5

[Mike Holderness]

It's a timing question. 

See http://www.londonfreelance.org/forms/testpop2.html

- which invokes a setTimeout before resizing the window. 

On a 600MHz Celeron the threshhold is in 5-10 ms region.

And I have an interesting question about the scope of 
arguments passed to the child window process - see 
test case above. Can someone who understands argument
scoping assign that as a new bug, or not?

Comment 6

[Russell Odom]

Confirming the workaround: add a short wait (e.g. with setTimeout()) before
calling getElementById() on the generated content. See
http://www.virginholidays.co.uk/js/snow.js - our threshold on a 1GHz PIII was
somewhere between 50 and 100ms; we left it at 1000ms to be on the safe side.

Adding to summary to make bug easier to find.

Comment 7

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 8

[Boris Zbarsky [:bzbarsky]]

So the basic problem here is that getElementById doesn't flush the content
model, no?

Comment 9

[Boris Zbarsky [:bzbarsky]]

Actually, 'tis a dup.

*** This bug has been marked as a duplicate of 29053 ***