XULRunner wizard does not work, if I read document.documentElement

UNCONFIRMED
Unassigned

Status

()

Core
DOM
--
critical
UNCONFIRMED
10 years ago
4 years ago

People

(Reporter: Georg Maaß, Unassigned)

Tracking

unspecified
x86
Windows XP
Points:
---
Bug Flags:
wanted1.9.2 ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

1.16 KB, application/zip
Details
612 bytes, application/vnd.mozilla.xul+xml
Details
(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061113 SeaMonkey/1.5a
Build Identifier: XULRunner: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9a5pre) Gecko/20070517

I created with XUL a wizard with wizard as document root element. If I read from the document.documentElement in JavaScript, the wizzard no longer works. Most elements in the wizard are no longer displayed and the back and next buttons are enabled. (back must not be enabled on the first page). Klick on them does not do anything. But on JavaScript side everything seems ok.

This displays correctly "wizard"
alert(self.document.documentElement.nodeName);

This means from JavaScript side document.documentElement is fully usable, but using it causes the wizzard to no longer work.

The problem has been detected first time with nighly from 2007-05-09 but may be older. In the newest available nightly from 2007-05-17 it is still present.

Reproducible: Always

Updated

10 years ago
Severity: critical → major

Updated

10 years ago
Severity: major → critical
Assignee: general → nobody
QA Contact: ian → general

Comment 1

8 years ago
Created attachment 399803 [details]
test case demonstrating problem

Something definitely goes wrong if you try to read the document.documentElement property of an XUL dialog before the dialog fully loads.  In this case, the contents of the dialog disappear. This does not occur for XUL windows, only dialogs.  

I noticed this when trying to load jquery-1.3.2 in my extension, but it can be easily reproduced via the attached test case. 

test-dialog.xul and test-window.xul both reference test.js via a script element.  test-dialog.js contains just the following code:

if (document.documentElement) { 
    // now the contents disappear     
}

if you comment this line of code out, you see the dialog contents correctly, if you leave it in, all except the OK button disappears.

Tested in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 GTB5 (.NET CLR 3.5.30729)

Updated

8 years ago
Flags: wanted1.9.2?
For a dialog, the problem is that you're forcing XBL binding attachment before the document has fully loaded, and the dialog binding doesn't appear to deal with the DOM being modified under it.  At least that's my best guess for what's going on here.

Comment 3

7 years ago
cross reference: http://dev.jquery.com/ticket/4443

Comment 4

6 years ago
I can confirm that this is having a real effect on extensions in use now.

I think it is ok to access documentElement when the window has loaded.

The Download Statusbar extension <https://addons.mozilla.org/en-US/firefox/addon/download-statusbar/> access this property 200ms after the main browser window loses focus, causing a race condition which catches my extension a lot of the time.

Affected <dialog> windows appears blank (without showing any widgets), but does show the ok button.

Affects both firefox 3 and firefox 4 beta 10 on my i486 ubuntu box.

Comment 5

6 years ago
Created attachment 510184 [details]
Detailed test case

Test case is an xul file like:
<dialog><label value="first" /><script> window.document.documentElement </script><label value="second" /></dialog>

When the script accesses the root node (via window.document.documentElement or window.document.firstChild) or accesses any other node (via window.document.getElementsByTagName("label")[0]); the second label will not load.

The problem appears to be specific to <dialog />. When I do a similar test with <window /> or with <root-element /> (the parent binding of <dialog />) the bug does not happen.
still an issue ?
You need to log in before you can comment on or make changes to this bug.