900724 - Prevent form-association when creating elements in template contents.

Status: RESOLVED FIXED

(Core :: DOM: HTML Parser, defect)

Description

[William Chen [:wchen]]

Update the <template> parser implementation to disallow form association of elements in template content. e.g.

<form><template><input></template></form>
<template><form><input></form></template>

The <input> elements should not be associated with the <form> elements.

http://html5.org/tools/web-apps-tracker?from=8114&to=8115

Comment 1

[William Chen [:wchen]]

Attachment: Prevent form association when creating elements in template contents.

I ran into a related bug while working on the update. In the following markup:

<template><form><input></form></template>

According to the spec (http://www.whatwg.org/specs/web-apps/current-work/#association-of-controls-and-forms), the input should not be associated with the form element because it is not inserted into a document. However, this is not the case in Gecko because we do not check the "inserted into a document" bit.

I've excluded this case from my tests. I rather fix the issue in a follow-up bug since it is a different problem.

Comment 2

[William Chen [:wchen]]

Attachment: Tests to ensure form association does not occur when creating elements in template contents.

Comment 3

[Henri Sivonen (:hsivonen)]

Comment on attachment 784798 [details] [diff] [review]
Prevent form association when creating elements in template contents.

Does the "form == null || " bit add value? It looks like an unnecessary comparison to me. r+ in any case.

Comment 4

[William Chen [:wchen]]

(In reply to Henri Sivonen (:hsivonen) from comment #3)
> Comment on attachment 784798 [details] [diff] [review]
> Prevent form association when creating elements in template contents.
> 
> Does the "form == null || " bit add value? It looks like an unnecessary
> comparison to me. r+ in any case.

For majority of the cases, form == null and I wanted to short circuit isTemplateContents() because it looks through the stack. I wasn't sure if the compiler would be able to optimize it. In any case, it reads closer to the spec so I've left it in there.

https://hg.mozilla.org/integration/mozilla-inbound/rev/cc84be0b4a5d

Comment 5

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

https://hg.mozilla.org/mozilla-central/rev/cc84be0b4a5d

Is the test upstreamable?

Comment 6

[William Chen [:wchen]]

(In reply to :Ms2ger from comment #5)
> https://hg.mozilla.org/mozilla-central/rev/cc84be0b4a5d
> 
> Is the test upstreamable?

I would say no because this test doesn't completely test the specified behavior. I left out some tests because I only fixed the parser piece but there is still a DOM piece that needs to be fixed.