Bug 3501 - HTMLScriptElement.text returns empty value
Summary: HTMLScriptElement.text returns empty value
Status: RESOLVED DUPLICATE of bug 3526
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 312.x
Hardware: Mac OS X 10.3
: P2 Normal
Assignee: Dave Hyatt
URL: http://www.declarativa.pt/script.htm
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-13 06:43 PDT by Mário Araújo
Modified: 2005-06-19 23:10 PDT (History)
0 users

See Also:


Attachments
Possible solution (tested and found working by Joost de Valk) (1.84 KB, patch)
2005-06-14 07:06 PDT, Niels Leenheer (HTML5test)
no flags Details | Formatted Diff | Diff
Extended testcase (1.20 KB, application/xhtml+xml)
2005-06-14 09:13 PDT, Niels Leenheer (HTML5test)
no flags Details
XHTML and HTML compatible patch (2.17 KB, patch)
2005-06-15 11:36 PDT, Niels Leenheer (HTML5test)
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mário Araújo 2005-06-13 06:43:55 PDT
The text property (the script content of the element) of the HTMLScriptElement 
(http://www.w3.org/TR/2000/CR-DOM-Level-2-20000510/html.html#ID-81598695) 
returns an empty value.
Comment 1 Niels Leenheer (HTML5test) 2005-06-14 07:06:41 PDT
Created attachment 2330 [details]
Possible solution (tested and found working by Joost de Valk)

The following patch is taken straight from KHTML, which is not affected
by this bug. Instead of look at the TEXT attribute, the text is now 
extracted from the TEXT child.
Comment 2 Ian 'Hixie' Hickson 2005-06-14 07:19:03 PDT
Comment on attachment 2330 [details]
Possible solution (tested and found working by Joost de Valk)

This doesn't handle the case where the <script> contains multiple text nodes,
or text nodes and cdata nodes, or text nodes and cdata nodes and comment nodes
and element nodes and entity nodes.

It should probably be a little cleverer. :-)
Comment 3 Niels Leenheer (HTML5test) 2005-06-14 09:09:57 PDT
Konqueror handles the following testcases just fine: CDATA, 
multiple nodes and mixed nodes types.

http://www.rakaz.nl/projects/safari/showscripts.html

Did you come to your conclusion after testing the patch, or
just from looking at the patch?

Comment 4 Niels Leenheer (HTML5test) 2005-06-14 09:13:16 PDT
Created attachment 2332 [details]
Extended testcase

This test case will also test for multiple nodes and mixed node types.
Comment 5 Joost de Valk (AlthA) 2005-06-14 23:43:48 PDT
At this time the patches won't build.
Comment 6 Joost de Valk (AlthA) 2005-06-15 00:33:23 PDT
Comment on attachment 2330 [details]
Possible solution (tested and found working by Joost de Valk)

JdV: works for me :)
Comment 7 Ian 'Hixie' Hickson 2005-06-15 02:42:16 PDT
Those two testcases are sent as text/html and therefore do not test the XML case
that I was referring to. (There are no comments or CDATA blocks in those
testcases, since they are parsed as HTML, in which the parser treats the entire
<script> element as having a single CDATA block.)

I'll change the testcase attached to this bug to have the right MIME type. Test
it again and you should see that it in fact doesn't work.

When running that test as XML you should see, for the .text attribute of each
<script> element in the file:

1. Two blank lines for the first <script> block ("\n\n"). (And indeed the entire
   test won't run when you send it as XML since the script that runs the test is 
   commented out.)
2. Two blank lines for the second <script> block.
3. The following for the third: "\n\nfunction noname2(){\n\t/*script*/\n\n}\n"
4. For the fourth: "\nfunction noname3(){\n\t/*script*/\n}\n"
5. Then: "\n\n\n"
6. The sixth is the following two strings concatenated (I couldn't fit them
   on one line here):
      "\n\nfunction noname5a(){\n\t/*script*/\n}\n" 
      "\n\nfunction noname5b(){\n\t/*script*/\n}\n"
7. And finally: "\n\n\nfunction noname6b(){\n\t/*script*/\n}\n\n"

...where of course "\t" is a tab character and "\n" is a newline character.

Also note that "document.getElementsByTagName("SCRIPT");" shouldn't work in
XHTML, you'll have to do this instead: 
   document.getElementsByTagNameNS("http://www.w3.org/1999/xhtml", "script")
Namely, you have to use lowercase and you have to use the *NS variant and give
the namespace.
Comment 8 Niels Leenheer (HTML5test) 2005-06-15 05:59:57 PDT
I've replaced the text() function with the following snippet() and it seems to
work, with one exception:

<script>
<[CDATA[

   ...

]]>
</script>

The newline between <script> and <[CDATA[ is not included. Neither is the
newline between ]]> and </script>. Those newlines should be of node type
TEXT_NODE, so the most probably cause is that they are stripped elsewhere,
because they only contain whitespace.


DOMString HTMLScriptElementImpl::text() const
{
    if (firstChild()) {
        QString scriptCode = "";
        NodeImpl *child;

        for (child = firstChild(); child; child = child->nextSibling()) {
            if (child->nodeType() == Node::TEXT_NODE || child->nodeType() ==
Node::CDATA_SECTION_NODE) {
                scriptCode += child->nodeValue().string();
            }
        }
        return scriptCode;
    }
    return "";
}

I still need to look at the other function. Replacing the text also becomes more
complicated, because we may need to replace multiple nodes with a single text
node...
Comment 9 Niels Leenheer (HTML5test) 2005-06-15 11:36:34 PDT
Created attachment 2368 [details]
XHTML and HTML compatible patch

A modified patch that is compatible with both documents that are parsed by the
XML parser and documents parsed by the HTML parser.

XML behavoir is tested with:
http://www.rakaz.nl/projects/safari/showscripts.php

HTML behavoir is tested with:
http://www.rakaz.nl/projects/safari/showscripts.html
Comment 10 Anders Carlsson 2005-06-16 01:36:23 PDT
Looks like the fix I did for 3256 fixes this as well (except for changing HTMLScriptElement::text() and 
setText() to call the implementation)
Comment 11 Niels Leenheer (HTML5test) 2005-06-19 14:30:52 PDT
This bug can be closed, the fix suggested in this bug is incorporated into the
patch for bug 3526.
Comment 12 Anders Carlsson 2005-06-19 23:10:21 PDT

*** This bug has been marked as a duplicate of 3526 ***