330426 - Script elements in XUL documents have no child nodes (with inline scripts)

Status: NEW

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

Description

[Alex Vincent [:WeirdAl]]

In a XUL document, XUL and HTML script elements do not have child nodes with inline scripts.  CVS blame points the finger at bug 105137.

This violates DOM Level 1 Core in that the child node has never been added.

This violates DOM Level 1 HTML for <html:script/> in that the text property is an empty string.

This is going to seriously crimp the style of Verbosio.  I hope to edit XUL applications with it.

Comment 1

[Alex Vincent [:WeirdAl]]

Attachment: testcase

Steps to reproduce:

(1) Open the attached testcase in Firefox or SeaMonkey.
(2) Note the alert contents, and compare them to a view-source of the document.

Expected results:
* alert contents should show child nodes of the script elements

Actual results:
* alert contents show the script elements as having no child nodes

DOM Inspector confirms these nodes have no children.

Comment 2

[Alex Vincent [:WeirdAl]]

Attachment: stab in the dark (doesn't work)

This is an initial, and unsuccessful, attempt to fix the bug.  I figured FlushText was at the heart of the bug, but I wasn't able to find the right changes in that function alone to create a fix.

I note that nsXULContentSink::FlushText() differs significantly from nsXMLContentSink::FlushText().  With the exception of whitespace handling, I don't see why that would be necessary or desirable.

Comment 3

[Robert Sayre]

The problem at root seems to be that nsXULPrototypeScript does not have fields for children the way nsXULPrototypeElement does. See /content/xul/content/src/nsXULElement.h#232 and /content/xul/content/src/nsXULElement.h#310 for the types.

If the script type had children, it could be treated similarly to a regular element in nsXULContentSink::HandleEndElement, where the buffers are flushed and the elements added to.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Perhaps the right approach is to make nsXULPrototypeScript inherit from nsXULPrototypeElement instead of nsXULPrototypeNode and then remove some of that special-casing?

Comment 5

[Alex Vincent [:WeirdAl]]

You read my mind, but I wasn't prepared to suggest that. :)

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yeah, that sounds like a good solution.

Comment 7

[Alex Vincent [:WeirdAl]]

So does anyone feel like taking this on besides me?  I can probably fix it, but it will take longer than more experienced hands and require more careful examination.

Comment 8

[Alex Vincent [:WeirdAl]]

From an e-mail beng sent me:

What do you want to know? You need to edit nsXULElement.h/cpp, change
the inheritance hierarchy for nsXULPrototypeScript (removing anything
that is unnecessary duplication, and leaving the serialize/deserialize
as is since the are special cased for XULPrototypeScripts.

Then take a look in nsXULContentSink.cpp/nsXULDocument.cpp for places
where these objects are constructed and initialized, and used, and
check to see if there are implications.

Here's some documentation about how XUL documents are loaded (yeah
yeah I know these need a way better home than this):
http://www.bengoodger.com/work-resources/tasks/fastload-xul/content-1.html

Comment 9

[Alex Vincent [:WeirdAl]]

Reassigning back to general@dom.  I'll continue to play with this, but I won't accept the bug again unless I have a patch.  If someone wants to take this on first, then by all means.  :)

Comment 11

[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.