432720 - <xul:script> in XMLDocument is not loaded or not executed

Status: NEW

(Core :: XUL, defect)

Description

[NathanielJayme]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5

When a xul page loads a dialog window it does not recoognize the javascript codes if the file extension does not end in 'xul'.

Reproducible: Always

Steps to Reproduce:
1.Create a dialog xul but don't end the file extension in xul (i.e. wnd.xul.dlg)
2.Create an internal or external javascript accept or cancel handler
3.Create a xul file that loads the dlg (file:// protocol)
Actual Results:  
The dialog window should recognize the javascript functions for accept and/or cancel handler, but it cannot resolve those functions.


Expected Results:  
Recognize the accept or cancel handler functions.

Comment 1

[Jesse Ruderman]

Can you attach a simple but complete testcase that demonstrates the bug?

Why are you giving the file an extension other than XUL?

Comment 2

[NathanielJayme]

Attachment: testcase for the dialog bug

this is the testcase for the openDialog bug.

Comment 3

[NathanielJayme]

i usually place the last part of the file as an identification of what kind of xul it is.  I expected Mozilla (SDK / Xulrunner) to check on the content rather than rely on the extension of the file.

Well, probably i'll stick to xul extensions from now on. 

;)

Comment 4

[Jesse Ruderman]

I can reproduce by just loading the .dlg file in Firefox; there's no need for testcase.xul with the openDialog call.

I'm surprised Firefox figures out the .dlg file is XML at all.  But given that it does, it's pretty weird that the script doesn't work.  The same thing happens if I give it a .xml extension.  I bet it has something to do with the document being an XMLDocument instead of a XULDocument.

Related to bug 380537, perhaps?

Comment 5

[Nickolay_Ponomarev]

> I bet it has something to do with the
> document being an XMLDocument instead of a XULDocument.
Yes, the logic for loading <xul:script>s is in the XUL content sink (which is invoked only for documents with XUL content type).

> Related to bug 380537, perhaps?
> 
No. bug 21771 is related though.

This is not easy to fix, and there are multiple other differences between generic XML documents and XUL. You should try to always use XUL in XUL documents only.

Comment 6

[NathanielJayme]

I have no idea behind the parser (so my thought may be too stupid)... should not the xmlns give a hint on how to handle the document?

Comment 7

[Nickolay_Ponomarev]

That's not how parsing works in mozilla. One reason could be that by the time you can get to xmlns declaration on the root element, you'd already have to create the document object and start parsing it.

Comment 8

[Aiko]

Isn't this related to bug 101147 (and thus WONTFIX)?

Comment 9

[Jesse Ruderman]

This "affects" content/xul/content/crashtests/107518-1.xml.