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




12 years ago
9 days ago


(Reporter: georg, Unassigned)


Windows XP
Bug Flags:
wanted1.9.2 ?

Firefox Tracking Flags

(Not tracked)



(2 attachments)



12 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"

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
Severity: critical → major
Severity: major → critical
Assignee: general → nobody
QA Contact: ian → general

Comment 1

10 years ago
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: Gecko/20090824 Firefox/3.5.3 GTB5 (.NET CLR 3.5.30729)


10 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

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

Comment 4

8 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

8 years ago
Posted file 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 ?

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.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.