Constructing a FormData from a form can lead to entries with lone surrogates
Categories
(Core :: DOM: Forms, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox90 | --- | fixed |
People
(Reporter: andreu, Assigned: andreu)
References
()
Details
Attachments
(1 file)
WPT test: https://wpt.fyi/results/html/semantics/forms/form-submission-0/form-data-set-usv.html?label=master&label=experimental&aligned (the second test)
According to the WebIDL definition for FormData, entry names should be scalar value strings, and so should entry values when they aren't files. However, when a FormData object is constructed from a form, lone surrogates in its controls' names and values will end up in the FormData object's entry list as is. While the IDL bindings restrict incoming values to be USVStrings, meaning that surrogate-containing entry names can't be observed from the API, it is possible to observe entry values with surrogates.
In the HTML spec, the conversion into scalar value strings of names and values coming from forms happens during the entry list construction, in the "append an entry" algorithm, at the same time as newlines are normalized to CRLF. Gecko (and WebKit) instead defer those conversions and normalizations until the form payload is encoded. Those behaviors used to be indistinguishable, until FormData was changed to allow inspection of its entry list from JS, whose consequences apparently weren't realized at the time. (See also bug 1657844 and bug 1651887.)
Now in https://github.com/whatwg/html/pull/6624 (together with https://github.com/whatwg/html/pull/6287) we're standardizing on Gecko's and WebKit's behavior of deferring the newline normalization, but we're leaving the USV conversion because it wouldn't make much sense to change FormData to work with DOMStrings.
Filing and taking.
|
||
Comment 1•3 years ago
|
||
Filing and taking.
Assigning you per the text 😀
|
Assignee | |
Comment 2•3 years ago
|
||
|
||
Comment 4•3 years ago
|
||
| bugherder | ||
Description
•