Bug #14988
closedxhtml_cleaning corrupts javascript in HTML-comment from extension
0%
Description
in my extension I want to write some javascript like:
$content.='
<script type="text/javascript">
</script>';
what ends up in the HTML-source of the resulting page is:
<script type="text/javascript">
<!--
function count_to(j) {
var s="";
for (var i=0; i<j; i="" s="i+"" alertscount_to10--="">
</script>
it seems that the cleaning is done inside of the HTML-comment.
Especially the '<' in the loop-header is mis-interpreted as an opening HTML-tag and anything following as parameter to this tag.
unsetting
page.config.xhtml_cleaning = all
leaves all javascript ok.
my workaround for this small part of code is using
for (var i=0; j>i; i++ ) {
instead of
for (var i=0; i<j; i++ ) {
But I think it can go worse if in the javascript a '<' is needed in a string.
BTW: I prepare the proper javascript-code with infos from within PHP, so I can't include the javascript from extern.
(issue imported from #M1477)
Files
Updated by Norbert Bernhardt over 18 years ago
I can confirm this strange behaviour of parsing or 'cleaning' within Javascript code when the code is added from an extension via
$GLOBALS['TSFE']->additionalHeaderData[$this->prefixId]=t3lib_div::wrapJS($jsCode)
regardless if xhtml_cleaning is set to 'all' or 'output'.
For example:
document.getElementById("nbnavre").style.visibility=((letztesBild==bilder||7<bilder)?"hidden":"visible");
document.getElementById("nbnavli").style.visibility=((letztesBild==6||7>bilder)?"hidden":"visible");
mutates to:
document.getElementById("nbnavre").style.visibility=((letztesBild==bilder||7<bilder)?"hidden":"visible"); documentgetelementbyidnbnavlistylevisibility="((letztesBild">bilder)?"hidden":"visible");
Bug report #0001292 reports a similar issues with RDF tags. (Status: Won't fix")
Updated by Franz Holzinger about 18 years ago
I can confirm this bug with tt_products 2.5.0.
During debugging of the reason why JavaScript generated in an extension gets changed wrongly by TYPO3 before output, I came to the function HTMLcleaner in class.t3lib_parsehtml.php.
The input string parts containing JavaScript
<script type="text/javascript">
/*<![CDATA[*/
/*]]>*/
</script>
gets split into 2 parts in class.t3lib_parsehtml.php on line 635.
$tagContent = substr($tok,$endTag,$tagEnd-$endTag);
part1:
...
if ((typeof(subcategories) "object") && (showSubCategories 1)) {
sb.options0 = new Option("", "A");
len = subcategories.length;
for (var k=0; k
part2:
len; k++) {
sb.options[k+1] = new Option(c[c[category]2[k]]0, c[category]2[k]);
}
} else {
bShowArticle = 1;
}
} else {
bShowArticle = 1;
}
...
This happens in the middle of the for loop.
at
k<len
.
Later the output of part2 gets totally corrupted.
for (var k=0; k<len; k="" sboptionsk1="new" optioncccategory2k0="" ccategory2k="" else="" bshowarticle="" if="" sboptions0="new" optionlen="" keineunterkategorie="" var="" data="" array="" sb="document.getElementById(" pid="" 2="" option="" b="" tx_ttproducts_pi1="" tt_products_showarticledata="" c="" sbselectedindex="0;" selectselectedindex="index;" keinenartikelanzeigen="" test="" --="">
/*]]>*/
What has been the intention of HTMLcleaner? Should it be able to handle JavaScript code as well?
- Franz
Updated by Norbert Bernhardt about 18 years ago
Function htmlcleaner in class.t3lib_parsehtml is not able to differ between HTML and Javascript code when 'cleaning' up the page (cleaning in terms of producing w³ compliant output). Thus is gets confused with the 'less than' sign and interpretes anything inside this 'tag' as an attribute.
Updated by Sebastian Kurfuerst about 18 years ago
Hi,
the option xhtml_cleaning is unstable (I think that is written in the documentation) and it is not suggested to use it. The core team will not provide support for it.
Greets, Sebastian
Updated by Franz Holzinger almost 18 years ago
Test the attached patch and give me a feedback. Then this should go into TYPO3Core (see mailings topic 'HTMLcleaner wrongly cleans JavaScripton' on dev list).
Updated by Michael Stucki over 17 years ago
Added a much simplified version. TODO: CDATA parts need to be added if missing...
Updated by Sascha Egerer about 17 years ago
Thanks for this Patch!!
Now it's works like should work... I hope that this is in the next release included..
Updated by Franz Holzinger about 17 years ago
Hello Michael,
you have now added a new functionalitiy.
I have still not got any feedback about my latest patch. Is something wrong with it?
- Franz
Updated by Michael Stucki about 17 years ago
I can't remember the reason exactly. Probably it was because my <script> tags had no CDATA wrapped around? I don't know...
But if you are convinced it works, go ahead and submit it to the core list.
Updated by Ingo Renner about 17 years ago
we had the same issue with some RDF code peace in a comment comming from TIMTAB. We at that time decided to leave xhtml_cleaning as it is.
The reason was/is that this feature is marked experimental and that one should produce good quality HTML code by default so that xhtml_cleaning is not needed at all.
Updated by Benni Mack over 16 years ago
As there are so many versions of this patch now, can somebody send a clean (made against 4.2 branch) patch to the core list so people can review it again?
Thanks!
Updated by Franz Holzinger over 16 years ago
What is wrong with my patch? What is missing? What should be changed?
It has already been sent to the Core list.
Updated by Benni Mack over 16 years ago
Hey Franz,
if your patch is the right one (I have not checked any patches yet) please either send a reminder of your patch request or resubmit your patch (as you sent it to the list before it was opened for everybody and then it got lost) to the core list.
Updated by Franz Holzinger over 16 years ago
Hello Benjamin,
I cannot judge about this.
If you do not care about speed and memory consumption, then the others patches would be better.
But if you want to have it fast and not eating much memory, then use my patch.
If you have fear of failures, then show me what does not work, and I will fix these issues,
Updated by Franz Holzinger over 15 years ago
This is really time critical. I have got this error message on a big site with TYPO3 4.2.3:
"Fatal error: Maximum execution time of 30 seconds exceeded in /home/bigsite/public_html/typo3_src-4.2.3/t3lib/class.t3lib_parsehtml.php on line 1329"
Updated by Thomas Deinhamer almost 13 years ago
- Target version changed from 0 to 4.5.7
It seems this is still an issue in 4.5.6.
Updated by Chris topher almost 13 years ago
- Target version changed from 4.5.7 to 4.5.8
Updated by Ernesto Baschny over 12 years ago
- Target version changed from 4.5.8 to 4.5.12
Updated by Riccardo De Contardi almost 10 years ago
Could this be closed? As far as I can see all the "related/duplicated as" bugs are marked either as closed or resolved
Updated by Mathias Schreiber over 9 years ago
- Description updated (diff)
- Status changed from New to Closed
- TYPO3 Version changed from 3.8.0 to 4.5
- PHP Version deleted (
4) - Is Regression set to No
I'm damn sure we fixed this two weeks ago.
Can you cross-check in in case we did not, please re-open the issue?