589073 - When an element is in a form which is in a form, while parsing, the element's form owner is the top one

Status: RESOLVED WONTFIX

(Core :: DOM: HTML Parser, defect)

Description

[Mounir Lamouri (:mounir)]

This is part of a test I just wrote and is weirdly failing:
  <form id='e'>
    <form id='f'>
      <input id='i3'>
      <script>
        todo_is(document.getElementById('i3').form, document.getElementById('f'),
                "While parsing, the form property should work.");
      </script>
    </form>
  </form>
  <form id='g'>
    <input id='i4'>
    <script>
      is(document.getElementById('i4').form, document.getElementById('g'),
         "While parsing, the form property should work.");
    </script>
  </form>

We agree that in the first part, the form owner should be 'f' (and not 'g').
The second part is working correctly.

FYI, when landed, the patch will be: content/html/content/test/test_bug588683-2.html (bug 588683)

Comment 1

[Henri Sivonen (:hsivonen)]

The spec says:
> A start tag whose tag name is "form"
>
>   If the form element pointer is not null, then this is a parse error; ignore >   the token.

Thus, the second form start tag is ignored becase the first one alreasy set the form pointer to a non-null value.

Is there a reason to believe that this isn't the desired behavior for Web compat?

Comment 2

[Mounir Lamouri (:mounir)]

(In reply to comment #1)
> The spec says:
> > A start tag whose tag name is "form"
> >
> >   If the form element pointer is not null, then this is a parse error; ignore >   the token.
> 
> Thus, the second form start tag is ignored becase the first one alreasy set the
> form pointer to a non-null value.
> 
> Is there a reason to believe that this isn't the desired behavior for Web
> compat?

There is no web compat hurt I think considering the form owner is correct when the parsing is finished (when BindToTree is called, the element find it's real form owner).
I think you probably can always consider the last form as the form owner of the following elements but if there is no easy fix for that, maybe we can live with it...

Comment 3

[Henri Sivonen (:hsivonen)]

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/616 log "e", "g" as expected per spec. Since there's no Web compat issue, not treating this as something needing a change in the parser or the spec.

Comment 4

[Mounir Lamouri (:mounir)]

(In reply to comment #3)
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/616 log "e", "g" as
> expected per spec. Since there's no Web compat issue, not treating this as
> something needing a change in the parser or the spec.

What part of the specifications say that 'f' should be ignored in that situation?

Comment 5

[Henri Sivonen (:hsivonen)]

(In reply to comment #4)
> (In reply to comment #3)
> > http://software.hixie.ch/utilities/js/live-dom-viewer/saved/616 log "e", "g" as
> > expected per spec. Since there's no Web compat issue, not treating this as
> > something needing a change in the parser or the spec.
> 
> What part of the specifications say that 'f' should be ignored in that
> situation?

Under http://www.whatwg.org/specs/web-apps/current-work/#parsing-main-inbody :
'A start tag whose tag name is "form"

    If the form element pointer is not null, then this is a parse error; ignore the token.

    Otherwise:

    If the stack of open elements has a p element in button scope, then act as if an end tag with the tag name "p" had been seen.

    Insert an HTML element for the token, and set the form element pointer to point to the element created.'

So <form id='e'> sets the form element pointer to non-null and <form id='f'> gets ignored by the parser.