Interesting Shindig bug

[Lev Epshteyn <le...@google.com>]

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.

Re: Interesting Shindig bug

[Louis Ryan <lr...@google.com>]

I would look in HTMLContentRewriter.rewriteJSTags

On Mon, Jan 26, 2009 at 11:11 AM, Lev Epshteyn <le...@google.com> 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 <lr...@google.com> 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 <et...@google.com> wrote:
> >
> > > On Thu, Jan 22, 2009 at 3:58 PM, Lev Epshteyn <le...@google.com>
> 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 <et...@google.com> wrote:
> > >>
> > >> > On Thu, Jan 22, 2009 at 3:28 PM, Lev Epshteyn <le...@google.com>
> > 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 <et...@google.com>
> > wrote:
> > >> > >
> > >> > > > On Thu, Jan 22, 2009 at 2:46 PM, Lev Epshteyn <levik@google.com
> >
> > >> > 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.
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>

Re: Interesting Shindig bug

[Lev Epshteyn <le...@google.com>]

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 <lr...@google.com> 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 <et...@google.com> wrote:
>
> > On Thu, Jan 22, 2009 at 3:58 PM, Lev Epshteyn <le...@google.com> 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 <et...@google.com> wrote:
> >>
> >> > On Thu, Jan 22, 2009 at 3:28 PM, Lev Epshteyn <le...@google.com>
> 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 <et...@google.com>
> wrote:
> >> > >
> >> > > > On Thu, Jan 22, 2009 at 2:46 PM, Lev Epshteyn <le...@google.com>
> >> > 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.
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>

Re: Interesting Shindig bug

[Louis Ryan <lr...@google.com>]

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 <et...@google.com> wrote:

> On Thu, Jan 22, 2009 at 3:58 PM, Lev Epshteyn <le...@google.com> 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 <et...@google.com> wrote:
>>
>> > On Thu, Jan 22, 2009 at 3:28 PM, Lev Epshteyn <le...@google.com> 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 <et...@google.com> wrote:
>> > >
>> > > > On Thu, Jan 22, 2009 at 2:46 PM, Lev Epshteyn <le...@google.com>
>> > 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.
>> > > >
>> > >
>> >
>>
>
>

Re: Interesting Shindig bug

[Kevin Brown <et...@google.com>]

On Thu, Jan 22, 2009 at 3:58 PM, Lev Epshteyn <le...@google.com> 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 <et...@google.com> wrote:
>
> > On Thu, Jan 22, 2009 at 3:28 PM, Lev Epshteyn <le...@google.com> 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 <et...@google.com> wrote:
> > >
> > > > On Thu, Jan 22, 2009 at 2:46 PM, Lev Epshteyn <le...@google.com>
> > 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.
> > > >
> > >
> >
>

Re: Interesting Shindig bug

[Lev Epshteyn <le...@google.com>]

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?

On Thu, Jan 22, 2009 at 6:44 PM, Kevin Brown <et...@google.com> wrote:

> On Thu, Jan 22, 2009 at 3:28 PM, Lev Epshteyn <le...@google.com> 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 <et...@google.com> wrote:
> >
> > > On Thu, Jan 22, 2009 at 2:46 PM, Lev Epshteyn <le...@google.com>
> 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.
> > >
> >
>

Re: Interesting Shindig bug

[Kevin Brown <et...@google.com>]

On Thu, Jan 22, 2009 at 3:28 PM, Lev Epshteyn <le...@google.com> 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 <et...@google.com> wrote:
>
> > On Thu, Jan 22, 2009 at 2:46 PM, Lev Epshteyn <le...@google.com> 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.
> >
>

Re: Interesting Shindig bug

[Lev Epshteyn <le...@google.com>]

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.

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.

On Thu, Jan 22, 2009 at 6:06 PM, Kevin Brown <et...@google.com> wrote:

> On Thu, Jan 22, 2009 at 2:46 PM, Lev Epshteyn <le...@google.com> 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.
>

Re: Interesting Shindig bug

[Kevin Brown <et...@google.com>]

On Thu, Jan 22, 2009 at 2:46 PM, Lev Epshteyn <le...@google.com> 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.