97841 - 2nd document.write mungs document.height to 0

Status: RESOLVED WORKSFORME

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

Description

[Robert Munyer]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.3+) Gecko/20010831
BuildID:    2001083110

If document.write replaces a document which was generated by a
previous document.write, document.height is incorrectly set to 0.

Reproducible: Always
Steps to Reproduce:
1. View the attached HTML document.
2. Notice the incorrect output.
   ... also ...
3. Click the "Reload" button.
4. Notice the blank page.

Actual Results:
Height of document "<P>foo":
Try #1: document.height == 16
Try #2: document.height == 0
Try #3: document.height == 0
Try #4: document.height == 0

Expected Results:
Height of document "<P>foo":
Try #1: document.height == 16
Try #2: document.height == 16
Try #3: document.height == 16
Try #4: document.height == 16

The attached HTML document works correctly in NN 4.  It also
works in MSIE, if you change ".height" to ".body.offsetHeight".

Comment 1

[Robert Munyer]

Attachment: Page that uses document.write, checks document.height, repeats

Comment 2

[Robert Munyer]

Attachment: Same content, with DOCTYPE (validates as HTML 4.01)

Comment 3

[Greg K.]

Reporter, can you produce a more minimal testcase that doesn't use frames? Make it as 
simple as possible.

Comment 4

[Robert Munyer]

Because the bug is triggered by interleaved use of document.write
and document.close, the test case has to use multiple frames or
multiple windows (or a quine!).  I am enclosing a test case that
uses windows instead of frames.  To run this test case, you will
need a Mozilla build that does not suffer from bug #92061.

Comment 5

[Robert Munyer]

Attachment: Test case that uses windows instead of frames

Comment 6

[Fabian Guisset]

This new testcase is blocked by the security manager:
"Attempt to load a javascript: URL from one host
in a window displaying content from another host
was blocked by the security manager."

Comment 7

[Robert Munyer]

In build #2001090508, bug #92061 has been fixed, so the message
reported above by Fabian Guisset does not appear.  But there's
another security manager bug blocking the third test case above;
it's been filed as bug #99454.  You'll need to wait for that bug
to be fixed before you can use the third test case.  Until then,
you can still use the first two test cases for this bug.

Comment 8

[Greg K.]

Robert, when viewing the source of each frame, I notice each begins with "undefined." Do 
you know what this is about? Could this have anything to do with the problem?

Comment 9

[Robert Munyer]

No, you've found an unrelated bug in View Source (View Source has
many problems; see the discussion of bug #55583).  Where you are
seeing "undefined", you should instead be seeing the value of the
variable baz, which is just a string that holds the doctype.

How to prove that the "undefined" is just a View Source problem:
(1) Change the test case so that the body of the document is also
accessed through a variable; now View Source will "lose" the
entire document, but you will still see the body in the window.
(2) Change the test case so that the doctype is not accessed
through a variable; now View Source will show the whole document
correctly, but the original problem (document.height incorrectly
set to 0) will still occur.

I will attach these two modified test cases.  They both validate,
they both work correctly in NN 4, and they both work correctly in
MSIE if you change ".height" to ".body.offsetHeight".

Comment 10

[Robert Munyer]

Attachment: This one exacerbates the View Source problem

Comment 11

[Robert Munyer]

Attachment: This one eliminates the View Source problem

Comment 12

[Greg K.]

Reporter, can you still reproduce this using 0.9.5?

Comment 13

[Robert Munyer]

Yes, 0.9.5 shows the same behavior.  All test cases (except the
third) show a reasonable number for document.height on the first
try, but then show 0 on all subsequent tries.  The third test
case throws an exception because of bug #99454.  Same as before.

Comment 14

[Boris Zbarsky [:bzbarsky]]

confirming this fairly old bug.  jst, any ideas what's up here?

Oh. I see it on Linux, so OS=ALL

Comment 15

[Johnny Stenback (:jst)]

WORKSFORME on Win2k and Linux.