Remove parserAdd from DocumentOrderedList.

Remove parserAdd from DocumentOrderedList.

Since HTMLParser reparents elements (including HTMLStyleElement), we cannot expect that all elements are
given in the document order. So we need to find where the given element is inserted into DocumentOrderedList.

BUG=353564
TEST=third_party/WebKit/LayoutTests/fast/dom/HTMLStyleElement/parser-reparent.html

Committed: https://crrev.com/2cd49bb3ebb9ce32d49aa2dd7a80ca0593855890
Cr-Commit-Position: refs/heads/master@{#353247}

[tasak, 2015-10-08 02:23:06]

tasak@google.com changed reviewers:
+ kochi@chromium.org, kouhei@chromium.org

[tasak, 2015-10-08 02:23:06]

Would you review this CL?

[kouhei (in TOK), 2015-10-08 02:26:54]

On 2015/10/08 02:23:06, tasak wrote:
> Would you review this CL?

Please measure perf impact of this CL.
I'm not sure if still having parserAdd makes sense. Can we only have add()?

[tasak, 2015-10-08 02:33:39]

On 2015/10/08 02:26:54, kouhei (catching-up) wrote:
> On 2015/10/08 02:23:06, tasak wrote:
> > Would you review this CL?
> 
> Please measure perf impact of this CL.

Sure. I will try.

> I'm not sure if still having parserAdd makes sense. Can we only have add()?

Agreed. I removed parserAdd (my local first patch did).

[kochi, 2015-10-08 03:28:07]

tasak, could enlighten me how/why the red style in the
original layout test file can be removed from the ref
html?  Any pointer to the parser spec would be fine.

[tasak, 2015-10-08 04:40:34]

On 2015/10/08 03:28:07, Takayoshi Kochi wrote:
> tasak, could enlighten me how/why the red style in the
> original layout test file can be removed from the ref
> html?  Any pointer to the parser spec would be fine.

The first style element in the html file is placed after the second style
element, because of reparent.
i.e. the document order is not the same as "source line number" order.

[kochi, 2015-10-08 06:18:15]

On 2015/10/08 04:40:34, tasak wrote:
> On 2015/10/08 03:28:07, Takayoshi Kochi wrote:
> > tasak, could enlighten me how/why the red style in the
> > original layout test file can be removed from the ref
> > html?  Any pointer to the parser spec would be fine.
> 
> The first style element in the html file is placed after the second style
> element, because of reparent.
> i.e. the document order is not the same as "source line number" order.

I see, so the old code assumed that if the node is coming from parser,
it should be already sorted, which is not correct.

lgtm (defer interpretation of any performance number to kouhei)

[kouhei (in TOK), 2015-10-08 06:19:49]

On 2015/10/08 06:18:15, Takayoshi Kochi wrote:
> On 2015/10/08 04:40:34, tasak wrote:
> > On 2015/10/08 03:28:07, Takayoshi Kochi wrote:
> > > tasak, could enlighten me how/why the red style in the
> > > original layout test file can be removed from the ref
> > > html?  Any pointer to the parser spec would be fine.
> > 
> > The first style element in the html file is placed after the second style
> > element, because of reparent.
> > i.e. the document order is not the same as "source line number" order.
> 
> I see, so the old code assumed that if the node is coming from parser,
> it should be already sorted, which is not correct.
> 
> lgtm (defer interpretation of any performance number to kouhei)

lgtm. I think it makes sense to try land this. (I'll be perf sherrifing from
tomorrow anyway)

[tasak, 2015-10-09 05:22:32]

On 2015/10/08 06:19:49, kouhei (catching-up) wrote:
> On 2015/10/08 06:18:15, Takayoshi Kochi wrote:
> > On 2015/10/08 04:40:34, tasak wrote:
> > > On 2015/10/08 03:28:07, Takayoshi Kochi wrote:
> > > > tasak, could enlighten me how/why the red style in the
> > > > original layout test file can be removed from the ref
> > > > html?  Any pointer to the parser spec would be fine.
> > > 
> > > The first style element in the html file is placed after the second style
> > > element, because of reparent.
> > > i.e. the document order is not the same as "source line number" order.
> > 
> > I see, so the old code assumed that if the node is coming from parser,
> > it should be already sorted, which is not correct.
> > 
> > lgtm (defer interpretation of any performance number to kouhei)
> 
> lgtm. I think it makes sense to try land this. (I'll be perf sherrifing from
> tomorrow anyway)

I ran run-perf-tests for DOM, CSS, Layout, Parser, SVG, and ShadowDOM. I didn't
see any significant regressions.
I will try to land the patch.

[tasak, 2015-10-09 05:22:40]

The CQ bit was checked by tasak@google.com

[commit-bot: I haz the power, 2015-10-09 05:23:03]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1389333005/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1389333005/20001

[commit-bot: I haz the power, 2015-10-09 07:59:31]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-10-09 08:00:21]

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