Binary size tool: Don't escape text that won't be parsed.

Binary size tool: Don't escape text that won't be parsed.

Only text that will be sent through an HTML parser needs to be parsed.
Escaping more than that results in & and < and similar in the
output.

R=andrewhayden@chromium.org

BUG=412708
Committed: https://crrev.com/1dc8a928dcc8ddf51198f067e694de250e771891
Cr-Commit-Position: refs/heads/master@{#294176}

[Daniel Bratell, 2014-09-10 09:53:52]

bratell@opera.com changed reviewers:
+ andrewhayden@chromium.org

[Andrew Hayden (chromium.org), 2014-09-10 10:03:32]

I'm confused; your description indicates that we should stop escaping things
that aren't going to parsed as HTML, but certainly the textual content in the
spans and links is needing to be escaped. Is there a second layer of escaping
taking place or something that is causing the extra transformation?

[Daniel Bratell, 2014-09-10 11:38:09]

On 2014/09/10 10:03:32, Andrew Hayden wrote:
> I'm confused; your description indicates that we should stop escaping things
> that aren't going to parsed as HTML, but certainly the textual content in the
> spans and links is needing to be escaped. Is there a second layer of escaping
> taking place or something that is causing the extra transformation?

It is only the HTML parser that expands entities and the HTML parser is not used
when creating text nodes with scripts:

  document.createTextNode("<lt>");

or setting attributes with:
  
  document.body.setAttribute("color", "<something purple & green?>")

which is what the lib is doing. index.html is also setting the title with
innerHTML and there the escape() has to stay because innerHTML does invoke the
HTML parser. Had this instead been generated by the python script or on a
server, then it would have been a different matter, but client side javascript
that manually creates elements, no html parser involved and it goes directly to
the dom layer.

[Andrew Hayden (chromium.org), 2014-09-10 12:08:39]

On 2014/09/10 11:38:09, Daniel Bratell wrote:
> On 2014/09/10 10:03:32, Andrew Hayden wrote:
> > I'm confused; your description indicates that we should stop escaping things
> > that aren't going to parsed as HTML, but certainly the textual content in
the
> > spans and links is needing to be escaped. Is there a second layer of
escaping
> > taking place or something that is causing the extra transformation?
> 
> It is only the HTML parser that expands entities and the HTML parser is not
used
> when creating text nodes with scripts:
> 
>   document.createTextNode("<lt>");
> 
> or setting attributes with:
>   
>   document.body.setAttribute("color", "<something purple & green?>")
> 
> which is what the lib is doing. index.html is also setting the title with
> innerHTML and there the escape() has to stay because innerHTML does invoke the
> HTML parser. Had this instead been generated by the python script or on a
> server, then it would have been a different matter, but client side javascript
> that manually creates elements, no html parser involved and it goes directly
to
> the dom layer.

Thanks for the explanation. LGTM.

[Daniel Bratell, 2014-09-10 12:32:03]

The CQ bit was checked by bratell@opera.com

[commit-bot: I haz the power, 2014-09-10 12:32:29]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/bratell@opera.com/562623002/1

[commit-bot: I haz the power, 2014-09-10 12:41:49]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-09-10 12:41:50]

Try jobs failed on following builders:
  android_aosp on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_aosp/bu...)

[Daniel Bratell, 2014-09-10 14:57:14]

The CQ bit was checked by bratell@opera.com

[commit-bot: I haz the power, 2014-09-10 14:57:50]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/bratell@opera.com/562623002/1

[commit-bot: I haz the power, 2014-09-10 15:43:24]

Committed patchset #1 (id:1) as 0176c0744b9f0519f47d2ddf46c540bd6df61061

[commit-bot: I haz the power, 2014-09-10 15:45:39]

Patchset 1 (id:??) landed as
https://crrev.com/1dc8a928dcc8ddf51198f067e694de250e771891
Cr-Commit-Position: refs/heads/master@{#294176}

[Daniel Bratell, 2014-09-11 15:21:17]

Patchset #2 (id:20001) has been deleted