Bug 148870 – form.elements should reflect the element ordering after the HTML tree builder algorithm

• Status: RESOLVED
• Resolution: FIXED
• Component: Forms

[Ryosuke Niwa]

When the HTML tree builder algorithm re-orders elements inside table, etc...
form.elements should be updated to reflect such re-ordering.

e.g. parsing the following HTML
<form id=form>
<table>
<tr>
<td><input type="radio" name="radio1" id="r1" value=1></td>
<td><input type="radio" name="radio2" id="r2" value=2></td>
<input type="radio"  name="radio0" id="r0" value=0>
</tr>
</table>
</form>

should put r0 at form.elements[0].

[Ryosuke Niwa]

This bug was found by the newly added test:
LayoutTests/http/tests/w3c/html/semantics/forms/the-form-element/form-elements-nameditem-02.html

and both Firefox and Chrome pass this test.

[Radar WebKit Bug Importer]

<rdar://problem/22589879>

[Keith Rollin]

Created attachment 266827 [details]
Patch

[Ryosuke Niwa]

Comment on attachment 266827 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=266827&action=review

> Source/WebCore/html/FormAssociatedElement.cpp:54
> +    , m_designatedForm(form)

"designated" seems rather vague.  How about m_parserSetForm or m_formSetByParser?

[Keith Rollin]

(In reply to comment #4)

I thought about that. I even called it something like that at first. But I backed away from that because it wasn't apparent to me that only the parser would be constructing HTMLFormControlElements with non-NULL HTMLFormElements. I'm pretty sure that that's the case *now*, but I didn't see anything that would prevent some other context from specifying an HTMLFormElement. That's why I went with a more general term.

But if you disagree with that line of thought, let me know and I'll change it.

[Keith Rollin]

Created attachment 267012 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 267012 [details]
Patch

Rejecting attachment 267012 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-01', 'validate-changelog', '--check-oops', '--non-interactive', 267012, '--port=mac']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit

ChangeLog entry in LayoutTests/imported/w3c/ChangeLog contains OOPS!.

Full output: http://webkit-queues.webkit.org/results/537562

[Keith Rollin]

Created attachment 267015 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 267015 [details]
Patch

Clearing flags on attachment: 267015

Committed r193840: <http://trac.webkit.org/changeset/193840>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Darin Adler]

Comment on attachment 267015 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=267015&action=review

> Source/WebCore/html/FormAssociatedElement.h:91
> +    FormAssociatedElement(HTMLFormElement*);

Should be marked explicit.