Bug #14988


xhtml_cleaning corrupts javascript in HTML-comment from extension

Added by Bernd Wilke over 18 years ago. Updated over 9 years ago.

Should have
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


in my extension I want to write some javascript like:

<script type="text/javascript">


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+&quot;" alertscount_to10--="">

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.

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)


parsehtml.diff (1.63 KB) parsehtml.diff Administrator Admin, 2006-08-22 09:01
class.t3lib_parsehtml.diff (2.63 KB) class.t3lib_parsehtml.diff Administrator Admin, 2006-12-06 13:03
bug_1477_stucki.diff (2.77 KB) bug_1477_stucki.diff Administrator Admin, 2007-04-20 17:20

Related issues 5 (0 open5 closed)

Related to TYPO3 Core - Bug #14150: t3lib_parsehtml: tags in comments are handled (incorrectly)ClosedChris topher2004-05-11

Is duplicate of TYPO3 Core - Bug #14868: xhtml_cleaning cleans HTML comments which is not wanted in any case (working patch included)ClosedSebastian Kurfuerst2005-07-17

Has duplicate TYPO3 Core - Bug #15913: HTML cleaner corrupts Java Script codeClosedMichael Stucki2006-03-28

Has duplicate TYPO3 Core - Bug #16170: xhtml_cleaning = 1 disables toolbar in the RTE in my ExtensionClosedMichael Stucki2006-05-22

Has duplicate TYPO3 Core - Bug #18508: config.xhtml_cleaning = all mixes up inline JavaScript. Should be documented.ClosedMichael Stucki2008-03-28

Actions #1

Updated by Norbert Bernhardt about 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
regardless if xhtml_cleaning is set to 'all' or 'output'.

For example:

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

Actions #2

Updated by Franz Holzinger over 17 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">


gets split into 2 parts in class.t3lib_parsehtml.php on line 635.
$tagContent = substr($tok,$endTag,$tagEnd-$endTag);

if ((typeof(subcategories) "object") && (showSubCategories 1)) {
sb.options0 = new Option("", "A");
len = subcategories.length;
for (var k=0; k

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.

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

Actions #3

Updated by Norbert Bernhardt over 17 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.

Actions #4

Updated by Sebastian Kurfuerst over 17 years ago

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

Actions #5

Updated by Franz Holzinger over 17 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).

Actions #6

Updated by Franz Holzinger over 17 years ago

3013 is a duplicate to this.

Actions #7

Updated by Michael Stucki almost 17 years ago

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

Actions #8

Updated by Sascha Egerer almost 17 years ago

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

Actions #9

Updated by Franz Holzinger almost 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

Actions #10

Updated by Michael Stucki almost 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.

Actions #11

Updated by Ingo Renner over 16 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.

Actions #12

Updated by Benni Mack about 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?


Actions #13

Updated by Franz Holzinger about 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.

Actions #14

Updated by Benni Mack about 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.

Actions #15

Updated by Franz Holzinger about 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,

Actions #16

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"

Actions #17

Updated by Thomas Deinhamer over 12 years ago

  • Target version changed from 0 to 4.5.7

It seems this is still an issue in 4.5.6.

Actions #18

Updated by Chris topher over 12 years ago

  • Target version changed from 4.5.7 to 4.5.8
Actions #19

Updated by Ernesto Baschny about 12 years ago

  • Target version changed from 4.5.8 to 4.5.12
Actions #20

Updated by Riccardo De Contardi over 9 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

Actions #21

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?


Also available in: Atom PDF