Closed Bug 381168 Opened 17 years ago Closed 2 years ago

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

Categories

(Core :: XUL, defect, P5)

x86
Windows XP
defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: georg, Unassigned)

Details

Attachments

(2 files)

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
Severity: critical → major
Severity: major → critical
Assignee: general → nobody
QA Contact: ian → general
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)
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.
cross reference: http://dev.jquery.com/ticket/4443
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.
Attached 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 ?
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.
Priority: -- → P5
Component: DOM → DOM: Core & HTML

Hello! I have tried to reproduce this issue but unfortunately I was unsuccessful with fx 87.0a1(2021-02-15), 85.0.2 and 86.0b9 . Shriram does this issue still occur with the latest firefox versions?

Flags: needinfo?(kshriram18)

Sergiu Negritas,
I'm not sure.
Currently, I'm unable to test it on Windows XP platform. Are you able to access it to verify the issue there ?

Flags: needinfo?(kshriram18)

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: critical → --

I'm not really sure what this is, but it doesn't sound very relevant.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Component: DOM: Core & HTML → XUL
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: