Its probably still got a bug in the script block concatenation code because it doesnt distinguish based on script types
On Thu, Jan 22, 2009 at 4:00 PM, Kevin Brown <[email protected]> wrote: > On Thu, Jan 22, 2009 at 3:58 PM, Lev Epshteyn <[email protected]> wrote: > >> Ah - my mistake. I had it confused with the concatenation servlet, which >> still serves the content out of band as an include. >> >> By the way, I'm still seeing the content rewriter change the @type >> attributes on all my script tags unless disabled... Should that not have >> gone away with the new rewrite engine? > > > It should have been fixed. Louis? > > >> >> On Thu, Jan 22, 2009 at 6:44 PM, Kevin Brown <[email protected]> wrote: >> >> > On Thu, Jan 22, 2009 at 3:28 PM, Lev Epshteyn <[email protected]> wrote: >> > >> > > Well, it's Shindig that takes a separate .js file where this is not an >> > > issue, and puts its contents into an inline script block. >> > > >> > > It's my understanding that not only OpenSocial features, but also >> > > third-party JS libraries can be inlined this way, so we can't rely on >> the >> > > JS >> > > author being conscious of the possibility that their code will get so >> > > included and avoiding this problem string. >> > >> > >> > Your understanding is incorrect. We only inline shindig feature >> javascript. >> > >> > >> > > At first, I had thought that simply enclosing the script content in a >> > CDATA >> > > block would solve the issue, but that doesn't seem to be the case. >> > >> > >> > That would only work if the gadget was served as XHTML. Since internet >> > explorer still does not support XHTML, this isn't an option. Always >> escape >> > forward slashes. >> > >> > >> > > >> > > >> > > On Thu, Jan 22, 2009 at 6:06 PM, Kevin Brown <[email protected]> wrote: >> > > >> > > > On Thu, Jan 22, 2009 at 2:46 PM, Lev Epshteyn <[email protected]> >> > wrote: >> > > > >> > > > > I found a strange bug in shindig while adding a checkbox to sample >> > > > > container >> > > > > to support non-minified JS output. >> > > > > >> > > > > In the templates feature JS, some of our comments include usage >> > > examples, >> > > > > which contain the string "</script>". >> > > > > >> > > > > This is not a problem for a .js file, but when Shindig inlines >> this >> > > > content >> > > > > into a <script> block, the string causes all sorts of havoc in the >> > > > browser, >> > > > > causing it to terminate the script block prematurely. >> > > > > >> > > > > While this isn't an issue in minified mode, where comments get >> > stripped >> > > > > off, >> > > > > I am wondering if the problem can also occur if I have a closing >> > script >> > > > tag >> > > > > inside a string literal. I haven't actually tested this, so it's >> > > entirely >> > > > > possible that Shindig is smart enough to handle this edge case. >> > > > >> > > > >> > > > This isn't a "shindig bug", it's a well known browser limitation. >> > Always >> > > > escape the string "</script>" as "<\/script>" in javascript. >> Contrary >> > to >> > > > common belief, you don't need to do bizarre things like >> concatenating >> > > <scr >> > > > and ipt>. Simply escaping the forward slash is sufficient. >> > > > >> > > >> > >> > >
