WPT test: https://wpt.fyi/results/html/semantics/forms/form-submission-0/constructing-form-data-set.html?label=experimental&label=master&aligned In the spec, the "construct the entry list" algorithm is passed an optional "submitter" argument, which it uses to determine whether to include a button in the entry list. And the FormData constructor calls "construct the entry list" with no optional parameters. But in WebKit, a FormData object constructed in the form's submit event listener will contain the submitter in its entry list. This happens because in WebKit, the submitter is tracked by setting an input's m_isActivatedSubmit state, and when submit buttons are activated, the state is set, the form is submitted, and the state is then unset (in HTMLButtonElement::defaultEventHandler, ImageInputType::handleDOMActivateEvent, SubmitInputType::handleDOMActivateEvent). So the submitter state stays on during the entire form submission algorithm, including when firing the submit event. However, it seems like HTMLFormElement::submit also sets the submitter's m_isActivatedSubmit state, since otherwise no submitter would show up for implicit submission and form.requestSubmit() with no arguments. So it seems like setting the state in the activation handlers would be unnecessary.
Created attachment 447040 [details] Patch
Committed r286988 (?): <https://commits.webkit.org/r286988> All reviewed patches have been landed. Closing bug and clearing flags on attachment 447040 [details].
<rdar://problem/86437179>
Re-opened since this is blocked by bug 236006
This change is being reverted in https://bugs.webkit.org/show_bug.cgi?id=236006 as it broke form submission for forms containing multiple <input type="image">. This is the failure scenario: ``` <form enctype="multipart/form-data" method="post"> <input name="foo" type="image" alt="foo"> <input name="bar" type="image" alt="bar"> </form> ``` Before this change, the following (correct) request was generated: ``` ------WebKitFormBoundaryPAHF32AEjrF9R0YH Content-Disposition: form-data; name="bar.x" 10 ------WebKitFormBoundaryPAHF32AEjrF9R0YH Content-Disposition: form-data; name="bar.y" 4 ------WebKitFormBoundaryPAHF32AEjrF9R0YH-- ``` After the change, the following (incorrect) request was generated: ``` ------WebKitFormBoundaryRa2do7IyOliqOhG6 Content-Disposition: form-data; name="foo.x" 0 ------WebKitFormBoundaryRa2do7IyOliqOhG6 Content-Disposition: form-data; name="foo.y" 0 ------WebKitFormBoundaryRa2do7IyOliqOhG6-- ```
Blocked by bug 236324.
Created attachment 451822 [details] Patch
Comment on attachment 451822 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=451822&action=review r=me except we need a patch with a corrected ChangeLog. So please don’t commit this without fixing that. Also please consider my comment about the new test. > LayoutTests/fast/forms/image/multiple-image-inputs.html:6 > + description("Multiple image inputs should work correctly."); We’re missing a change log entry for this test and its expected result. That would be in LayoutTests/ChangeLog. Also wondering why we need our own WebKit-specific test for this. Could we have added this testing to WPT?
> Also wondering why we need our own WebKit-specific test for this. Could we > have added this testing to WPT? I didn't add this test to WPT because Firefox doesn't seem to use the position of mouse events when determining the selected coordinate. The spec doesn't say anything about mouse events in that regard, so WebKit and Blink might be wrong here, but that's not what I meant to test. In any case, I'll rewrite it as a WebDriver WPT test.
Created attachment 452693 [details] Patch
This patch modifies the imported WPT tests. Please ensure that any changes on the tests (not coming from a WPT import) are exported to WPT. Please see https://trac.webkit.org/wiki/WPTExportProcess
Looks like the test is not working yet on the ios-wk2 EWS, which runs tests on the iOS simulator.
(In reply to Darin Adler from comment #12) > Looks like the test is not working yet on the ios-wk2 EWS, which runs tests > on the iOS simulator. iOS doesn't support test_driver.Actions, so in this case having a special iOS baseline is fine.
*** This bug has been marked as a duplicate of bug 239070 ***