We’re using an ancient library called TrimPath to render templated data with JavaScript, and a peer hit the “unterminated string literal” in eval() on IE only. I assisted to solve it, by extracting the offending string and isolated the cause to a ‘\n’ within the string. It was easy to cut away the additional newlines and IE is happy. (This is on the assumption that the newline are decorative and not necessary as part of the output)
However, I wasn’t satisfied what caused the newline to be parsed wrongly, and why IE only. The good thing with Open Source is we get to dig in ourselves to troubleshoot issues.
After stepping through the cause is identified: multiple continuous \n not parsed correctly. Apparently someone hit this at least 5 years ago and there was a fix for it, by detecting the additional \n and eating it up. But it still fails if there are more \n.
Why IE only? We were using script tags as the template, and in IE script.innerHTML is prefixed with an additional \n.
The following snippet will fail in IE, but pass in FF.
If another newline is added (with no additional whitepsace), FF will fail with the same error.
If <textarea> instead of <script> is used, it will pass, but adding more newlines will also cause it to fail.
As an anecdote, I’m not sure how our project got to use 1.1.2, when the last on the download site is 1.0.38 (legacy stuff…). But a search on the web shows it’s not just us…
Haha – My team is also using this ancient library 🙂
I hit a similar issue, but interestingly, it wasn’t IE-specific – I had the problem in FF and Chrome on Mac. Removing multiple blank lines between macro definitions in the template fixed it in my case.
Thanks for the pointer.