Is this a difficult bug to locate? It's currently preventing the use of templates with any kind of content rewriting - requiring code to disable rewriting features for any gadget that wants to use templates.
I can look into fixing it - any suggestions on where you think I should start would be welcome. On Thu, Jan 22, 2009 at 7:26 PM, Louis Ryan <[email protected]> wrote: > 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. > >> > > > > >> > > > >> > > >> > > > > >
