Bug 148870

Summary: form.elements should reflect the element ordering after the HTML tree builder algorithm
Product: WebKit Reporter: Ryosuke Niwa <rniwa>
Component: FormsAssignee: Keith Rollin <krollin>
Severity: Normal CC: benjamin, cdumez, commit-queue, krollin, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Description Flags
Patch none

Description Ryosuke Niwa 2015-09-04 19:17:20 PDT
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>
<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>

should put r0 at form.elements[0].
Comment 1 Ryosuke Niwa 2015-09-04 19:17:58 PDT
This bug was found by the newly added test:

and both Firefox and Chrome pass this test.
Comment 2 Radar WebKit Bug Importer 2015-09-04 19:18:01 PDT
Comment 3 Keith Rollin 2015-12-07 16:18:38 PST
Created attachment 266827 [details]
Comment 4 Ryosuke Niwa 2015-12-07 16:51:05 PST
Comment on attachment 266827 [details]

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?
Comment 5 Keith Rollin 2015-12-07 17:02:35 PST
(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.
Comment 6 Keith Rollin 2015-12-09 08:49:57 PST
Created attachment 267012 [details]
Comment 7 WebKit Commit Bot 2015-12-09 09:22:04 PST
Comment on attachment 267012 [details]

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
Comment 8 Keith Rollin 2015-12-09 09:29:45 PST
Created attachment 267015 [details]
Comment 9 WebKit Commit Bot 2015-12-09 10:19:28 PST
Comment on attachment 267015 [details]

Clearing flags on attachment: 267015

Committed r193840: <http://trac.webkit.org/changeset/193840>
Comment 10 WebKit Commit Bot 2015-12-09 10:19:33 PST
All reviewed patches have been landed.  Closing bug.
Comment 11 Darin Adler 2015-12-10 12:06:15 PST
Comment on attachment 267015 [details]

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.