99956 - body.appendChild(H1) fails to display text from constructor

Status: RESOLVED INACTIVE

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

Description

[Steven T. Hatton]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010916
BuildID:    2001091606

When a window is opened by a constructor and a <H1> element is appended to the
body, the text is not displayed.  Certain factors can influence this behavior,
please see attached code. 

Reproducible: Always
Steps to Reproduce:
1. instantiate an object with a window.open in the constructor
2. within the same constructor create and append a <H1> element to the body
3. please see sample code

Actual Results:  No text is displayed in the newly opened window

Expected Results:  The header should be displayed

From my perspective this bug is of the same nature as: 98530. It may again be my
fault.  If this behavior is deemed correct, then I will contend there is a lack
of good documentation detailing what I _should_ expect, and the bug should be
listed as a documentation bug.

Comment 1

[Steven T. Hatton]

Attachment: sample code to reproduce the results

Comment 2

[Steven T. Hatton]

Attachment: a setTimeout("fn()", 0) workaround

Comment 3

[Steven T. Hatton]

NOTE WELL: There is a comma in the function WinTest3(, ) of the first attachment
which needs to be removed.  Sorry about the meta-bug.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: javascript for testcase

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: Same js as text/plain

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: HTML testcase. Click the buttons.

Comment 7

[Steven T. Hatton]

Attachment: window.open("","name",props) works demo

Comment 8

[Steven T. Hatton]

Thanks to Martin Honnen, *the* world renounded JavaScript expert, it has been
demonstrated that the problem does not exist when the URL parameter is an empty
string.  I attached a demo page for this. See: 49792.  I don't know if I can
reduce the importance of the bug myself, but I believe this is a much more
acceptable resolution than the setTimeout() workaround.  I will lower the
priority to minor if I find that I am able to.  If not, someone with the
authority to do so, please do this.  I still think there is a problem. If
nothing else, it should be a footnote in the documentation.

Comment 9

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 10

[Boris Zbarsky [:bzbarsky]]

Dup of the general 'window.open is async' deal.

Comment 11

[adminnu]

Bug is relevant, chrome bug does not manifest itself.

Comment 12

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.