WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 233725
File inputs in non-multipart form submissions show up as string values in the formdata event
https://bugs.webkit.org/show_bug.cgi?id=233725
Summary
File inputs in non-multipart form submissions show up as string values in the...
Andreu Botella
Reported
2021-12-01 14:13:55 PST
When a form's entry list is constructed, file inputs are being added to the DOMFormData object as entries with File values only if the entry list is being constructed as part of a multipart/form-data form submission or through the FormData constructor – for urlencoded and text/plain form submissions, file inputs are added as entries with a string value consisting of the file's filename. Before
r280310
, this followed the spec: this filename conversion is part of "convert to a list of name-value pairs" (
https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#convert-to-a-list-of-name-value-pairs
), except done earlier in the form submission than the rest of the normalization in that algorithm, and there was no way to observe the difference because the DOMFormData object was never exposed to the user halfway through a form submission.
r280310
changed this by adding the formdata event, which fires at the end of the "construct the entry list" algorithm and can both inspect and modify the DOMFormData object. This means that it is now observable that file inputs in urlencoded and text/plain form submissions are encoded as their filenames, which goes against the spec. Additionally, any new File entries added to the DOMFormData object in that event will be skipped when building the form payload, which also shouldn't happen. It looks like file inputs should always be added to DOMFormData as File values, and the conversion to a filename should happen in FormData::appendNonMultipartKeyValuePairItems, along with the rest of normalizations in "convert to a list of name-value pairs".
Attachments
Patch
(19.56 KB, patch)
2021-12-01 14:51 PST
,
Andreu Botella
no flags
Details
Formatted Diff
Diff
Patch
(19.68 KB, patch)
2021-12-01 18:02 PST
,
Andreu Botella
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Andreu Botella
Comment 1
2021-12-01 14:51:23 PST
Created
attachment 445620
[details]
Patch
EWS Watchlist
Comment 2
2021-12-01 14:52:25 PST
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
Chris Dumez
Comment 3
2021-12-01 16:56:51 PST
Comment on
attachment 445620
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=445620&action=review
> Source/WebCore/ChangeLog:10 > + filename. Before
r280310
, this optimizaton was unobservable, since the DOMFormData object
typo: optimizaton
> Source/WebCore/html/FileInputType.cpp:161 > +bool FileInputType::appendFormData(DOMFormData& formData, bool) const
Can we drop the boolean parameter completely now or is it still required for some reason?
> Source/WebCore/platform/network/FormData.cpp:277 > + if (std::holds_alternative<String>(item.data))
May be nice to use WTF::switchOn() here.
Chris Dumez
Comment 4
2021-12-01 16:58:47 PST
Comment on
attachment 445620
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=445620&action=review
> LayoutTests/imported/w3c/web-platform-tests/html/semantics/forms/form-submission-0/constructing-form-data-set.html:80 > +for (const enctype of ["application/x-www-form-urlencoded", "multipart/form-data", "text/plain"]) {
Is this a resync from upstream? or is there a corresponding PR on upstream WPT? The change log doesn't say and we cannot make changes to WPT downstream unless these changes are also made upstream.
Andreu Botella
Comment 5
2021-12-01 17:16:48 PST
Comment on
attachment 445620
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=445620&action=review
>> Source/WebCore/html/FileInputType.cpp:161 >> +bool FileInputType::appendFormData(DOMFormData& formData, bool) const > > Can we drop the boolean parameter completely now or is it still required for some reason?
It's no longer required, but it involves changes in every subclass of InputType and FormAssociatedElement, as well as removing the third parameter to HTMLFormElement::constructEntryList, so it's probably best to leave for a follow-up patch.
Andreu Botella
Comment 6
2021-12-01 17:18:52 PST
Comment on
attachment 445620
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=445620&action=review
>> LayoutTests/imported/w3c/web-platform-tests/html/semantics/forms/form-submission-0/constructing-form-data-set.html:80 >> +for (const enctype of ["application/x-www-form-urlencoded", "multipart/form-data", "text/plain"]) { > > Is this a resync from upstream? or is there a corresponding PR on upstream WPT? > > The change log doesn't say and we cannot make changes to WPT downstream unless these changes are also made upstream.
I opened
https://github.com/web-platform-tests/wpt/pull/31821
upstream.
Andreu Botella
Comment 7
2021-12-01 18:02:24 PST
Created
attachment 445650
[details]
Patch
Chris Dumez
Comment 8
2021-12-02 07:30:15 PST
Comment on
attachment 445650
[details]
Patch r=me
EWS
Comment 9
2021-12-02 07:34:08 PST
Committed
r286427
(
244773@main
): <
https://commits.webkit.org/244773@main
> All reviewed patches have been landed. Closing bug and clearing flags on
attachment 445650
[details]
.
Radar WebKit Bug Importer
Comment 10
2021-12-02 07:35:26 PST
<
rdar://problem/85970598
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug