HTMLTreeBuilderSimulator: Element created inside HTMLIntegrationPoint should be HTMLElement

HTMLTreeBuilderSimulator: Element created inside HTMLIntegrationPoint should be HTMLElement

Per the HTML spec, "If the adjusted current node is an HTML integration point and the token is a start tag" [1],
we should "process the token according to the rules given in the section corresponding to the current insertion mode in HTML content",
which should "insert an HTML element" [2].
[1] https://html.spec.whatwg.org/multipage/syntax.html#tree-construction
[2] https://html.spec.whatwg.org/multipage/syntax.html#insert-an-html-element

HTMLTreeBuilder already conforms to the spec.
This CL fixes the HTMLTreeBuilderSimulator so that it would also respect the spec behaviour:
The child element of HTMLIntegrationPoint element should be a HTML element, and
the grand child element of HTMLIntegrationPoint element should also be a HTML element if the
element doesn't start foreignContent.

BUG=411226

[kouhei (in TOK), 2016-07-20 08:00:59]

The CQ bit was checked by kouhei@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-20 08:01:26]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[kouhei (in TOK), 2016-07-20 08:39:07]

Description was changed from

==========
HTMLTreeBuilderSimulator: Element created inside HTMLIntegrationPoint should be
HTMLElement

BUG=411226
==========

to

==========
HTMLTreeBuilderSimulator: Element created inside HTMLIntegrationPoint should be
HTMLElement

Per the HTML spec, "If the adjusted current node is an HTML integration point
and the token is a start tag" [1],
we should "process the token according to the rules given in the section
corresponding to the current insertion mode in HTML content",
which should "insert an HTML element" [2].
[1] https://html.spec.whatwg.org/multipage/syntax.html#tree-construction
[2] https://html.spec.whatwg.org/multipage/syntax.html#insert-an-html-element

HTMLTreeBuilder already conforms to the spec.
This CL fixes the HTMLTreeBuilderSimulator so that it would also respect the
spec behaviour:
The child element of HTMLIntegrationPoint element should be a HTML element, and
the grand child element of HTMLIntegrationPoint element should also be a HTML
element if the
element doesn't start foreignContent.

BUG=411226
==========

[kouhei (in TOK), 2016-07-20 08:39:07]

kouhei@chromium.org changed reviewers:
+ dominicc@chromium.org

[kouhei (in TOK), 2016-07-20 08:40:07]

I still think we should commit https://codereview.chromium.org/2151783002/ too,
but this is an another bug uncovered from the crbug.com/411226 case.

[commit-bot: I haz the power, 2016-07-20 09:17:29]

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

[commit-bot: I haz the power, 2016-07-20 09:17:30]

Dry run: This issue passed the CQ dry run.

[kouhei (in TOK), 2016-07-20 09:29:07]

kouhei@chromium.org changed reviewers:
+ yosin@google.com

[kouhei (in TOK), 2016-07-20 09:29:43]

kouhei@chromium.org changed reviewers:
+ yosin@chromium.org
- yosin@google.com

[dominicc (has gone to gerrit), 2016-07-21 02:14:49]

Makes sense, but some questions inline.

https://codereview.chromium.org/2169433002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/html/parser/HTMLTreeBuilderSimulator.cpp
(right):

https://codereview.chromium.org/2169433002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/html/parser/HTMLTreeBuilderSimulator.cpp:179:
m_stack.append(StateFlags {HTML, false});
Why don't we need a matching change to "pop" this?

Why would an <svg> element at a HTML integration point not flip the namespace
back to SVG?

Could you add some pointers to specs and some stress tests for this sort of
thing?

https://codereview.chromium.org/2169433002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/html/parser/HTMLTreeBuilderSimulatorTest.cpp
(right):

https://codereview.chromium.org/2169433002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/html/parser/HTMLTreeBuilderSimulatorTest.cpp:59:
EXPECT_EQ(HTMLTokenizer::DataState, tokenizer->getState())
I'm mildly confused comparing the code of the assertion and the description.

Just going by the name of this test,
ChangeStateInForeignContentAtHTMLIntegrationPoint, having assertions about
states and foreign content seems natural here.

The assertion code seems to be about tokenizer states. How does that relate to
HTML namespaces? Can you write an assertion that gets more directly to the
namespace question? (Maybe have both state and namespace assertions?)