WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 3526
Bug 3501
HTMLScriptElement.text returns empty value
https://bugs.webkit.org/show_bug.cgi?id=3501
Summary
HTMLScriptElement.text returns empty value
Mário Araújo
Reported
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.
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
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Niels Leenheer (HTML5test)
Comment 1
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.
Ian 'Hixie' Hickson
Comment 2
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. :-)
Niels Leenheer (HTML5test)
Comment 3
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?
Niels Leenheer (HTML5test)
Comment 4
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.
Joost de Valk (AlthA)
Comment 5
2005-06-14 23:43:48 PDT
At this time the patches won't build.
Joost de Valk (AlthA)
Comment 6
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 :)
Ian 'Hixie' Hickson
Comment 7
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.
Niels Leenheer (HTML5test)
Comment 8
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...
Niels Leenheer (HTML5test)
Comment 9
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
Anders Carlsson
Comment 10
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)
Niels Leenheer (HTML5test)
Comment 11
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
.
Anders Carlsson
Comment 12
2005-06-19 23:10:21 PDT
*** This bug has been marked as a duplicate of
3526
***
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug