[Typo3-dev] RFC: Bug #277: utf-8 + JSMENU/feAdminLib

[Bernhard Kraft]

Hello,


The Zap-the-Gremlins team tries to fix the following bug:

http://bugs.typo3.org/view.php?id=277

And I would like to have some feedback.

The problem seems to evlove from the fact that VERY OLD browsers (3.x Netscape/IE) didn't support non-ASCII values
like Umlauts öäü and as a result of this no utf-8 strings in their alert('...') or similar methods. So the construct
unescape(\''.rawurlencode($str).'\')
was "invented".

Nowadays browsers support alert('日本語引数テストファイル') (Japanese - switch your mail-client to utf-8 for this post)
without any problems.

In these old days just the strings didn't get interpreted correctly .... but the parsers were almost the same as today.
The only thing you have to care about when you write an JS string enclosed for exmplae in single quotes ' is that you
quote any single quote in the string with a \ (backslash). i.e. 'Let's rock' should become 'Let\'s rock'.

This can get achieved by using the "addcslashes" php function:

$str = 'Let\'s rock. Heres a " doublequote'; 	// The \' is just because also php needs the ' escaped. Just a ' will get stored in the string.
$str = addcslashes($str, "'");			// Quote all '

Now you could use this string in any <script> tag:
$out .= '<script language="JavaScript" type="text/javascript">
alert(\''.$str.'\')
</script>';

So this would solve all problems in tslib/class.tslib_menu.php and feAdminLib.

When the String get's used in a onClick event additional measures need to be taken:

The contents of an tag attribute get's feed trough the HTML parser which replaces all entities (i.e.: &amp;) so you won't be happy if you want
to have the TEXT &amp; in the alert text (not converted to &). So you will first need to pass the string (or the complete onClick event) through
htmlspecialchars:

$out .= '<a .... onClick="'.htmlspecialchars('alert(\''.$str.'\')').' href="#">';

Note that the part "alert(\''.$str.'\')" didn't change at all. Just a htmlspecialchars was wrapped around it.

This will produce html code like

<a ... onClick="alert('Let\'s rock Heres a &quot; doublequote')" href="#">

also if you would have used doublequotes " for quoting the alert string it would be valid and look like the following:

<a ... onClick="alert(&quot;Let\'s rock&quot;)" href="#">

Which would be completly valid (first HTML entities get replaced by HTML parser. Then quoted characters get replaced by their original by the JS parser)


So my final result is that the unescape(rawurlencode()) construct should get dropped and replaced by propper quoting/specialchar'ing the text's and
drop support for 3.x browsers.

Does someone have major arguments against this step ?



greets,
Bernhard