GetElementById on document.writte()n content onload fails

VERIFIED WONTFIX

Status

()

Core
DOM: Core & HTML
P3
normal
VERIFIED WONTFIX
18 years ago
14 years ago

People

(Reporter: Robert Ginda, Assigned: jst)

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
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

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

Comment 2

18 years ago
more love.
Assignee: waterson → vidur
(Reporter)

Comment 3

18 years ago
This Just Works now.  Maybe I need to adjust my medication.
Marking WORKSFORME.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 4

18 years ago
Reopening, change writeStyle=false to writeStyle=true (in the testcase attached
to bug 29052) to see the failure.
Status: RESOLVED → REOPENED
Component: Event Handling → DOM Level 0
Resolution: WORKSFORME → ---
(Reporter)

Comment 5

18 years ago
Reassign to component owner.
Assignee: vidur → jst
Status: REOPENED → NEW
QA Contact: janc → desale
(Assignee)

Comment 6

18 years ago
This seems to have been fixed, marking FIXED.
Status: NEW → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 7

18 years ago
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'
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 8

18 years ago
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.

Target Milestone: --- → Future

Comment 9

17 years ago
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
(Assignee)

Comment 11

17 years ago
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?
OS: Linux → All
Hardware: PC → All
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
(Reporter)

Comment 13

17 years ago
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[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
(Assignee)

Comment 15

17 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → WONTFIX

Comment 16

17 years ago
WONTFIX
Status: RESOLVED → VERIFIED
*** Bug 165053 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.