I would look in HTMLContentRewriter.rewriteJSTags On Mon, Jan 26, 2009 at 11:11 AM, Lev Epshteyn <[email protected]> wrote:
> 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. > > >> > > > > > >> > > > > >> > > > >> > > > > > > > > >
