Odd bug caused by script tag in prefs.js feature comment

[Chris Chabot]

Hey All,

php-shindig's new gadget parser, which uses a dom parser, gets confused when
assigning a node value that contains a /* comment including a >script<
*/ .. as in it translates it back to <script>foo</script&lt;, which then
causes the browser to trip because of the unterminated script tag (odd btw
that it doesn't translate the last &lt; but that's irrelevant to the
proposed solution)

Would it be ok to remove that comment from core/prefs.js ? The patch would
be:

Index: src/main/javascript/features/core/prefs.js
===================================================================
--- src/main/javascript/features/core/prefs.js    (revision 764189)
+++ src/main/javascript/features/core/prefs.js    (working copy)
@@ -28,16 +28,6 @@
  *   var prefs = new gadgets.Prefs();
  *   var name = prefs.getString("name");
  *   var lang = prefs.getLang();
- *
- * Modules with type=url can also use this library to parse arguments
passed
- * by URL, but this is not the common case:
- *
- *   &lt;script src="http://apache.org/shindig/prefs.js"&gt;&lt;/script&gt;
- *   &lt;script&gt;
- *   gadgets.Prefs.parseUrl();
- *   var prefs = new gadgets.Prefs();
- *   var name = prefs.getString("name");
- *   &lt;/script&lg;
  */


We've had trouble with url's and script tags in comments before (as in
hundreds of thousands of 404's a day on apache's servers due to them), and
now this issue with the xml parser i'm using, possibly it would be safer not
to include any form of script tags in the comments? :) (this is the only
occurrence of a script tag left in the features).

Would like to have a second opinion before committing this 'patch'.

   -- Chris