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…
One thought to “Trimpath unterminated string literal in IE”
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.