TYPO3 Core

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")

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.options⁰ = new Option("", "A");
len = subcategories.length;
for (var k=0; k

part2:
len; k++) {
sb.options[k+1] = new Option(c[c[category]²[k]]⁰, c[category]²[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

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.

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

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

3013 is a duplicate to this.

Added a much simplified version. TODO: CDATA parts need to be added if missing...

Thanks for this Patch!!
Now it's works like should work... I hope that this is in the next release included..

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

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.

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.

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!

What is wrong with my patch? What is missing? What should be changed?
It has already been sent to the Core list.

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.

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,

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"

Could this be closed? As far as I can see all the "related/duplicated as" bugs are marked either as closed or resolved