Remove newline normalization in construct the entry list #6624
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
andreubotella
suggested changes
Apr 29, 2021
There was a problem hiding this comment.
LGTM except for the textarea case.
As for the double normalization notes in #6287, I think I'll remove them so this PR can be merged just after it.
| </li> | ||
| <li><p>Otherwise, if the <var>field</var> element is a <code>textarea</code> element, | ||
| <span>append an entry</span> to <var>entry list</var> with <var>name</var> and the <span | ||
| data-x="concept-fe-value">value</span> of the <var>field</var> element.</p></li> |
There was a problem hiding this comment.
<textarea> is a bit of a special case in that, in the current spec text, rather than being CRLF-normalized in the "append an entry" algorithm, it's normalized before that in the textarea wrapping transformation. But on Firefox and Safari, <textarea> values as observed from the FormData constructor are LF-normalized instead. And Firefox doesn't seem to implement wrap="hard", but Safari implements it by inserting LF newlines. So the wrapping transformation would have to be changed as well, though I'm not sure how that might interact with things like minlength.
There was a problem hiding this comment.
Can this be a follow-up to adjust that algorithm accordingly or does form submission actually have to know the data came from a textarea?
There was a problem hiding this comment.
Sure, it can be a follow-up.
cc @mfreed7 so they know they'll have to implement the follow-up as well.
There was a problem hiding this comment.
As it's an existing issue with <textarea> it seems best separated from this. We should probably also do some cross-platform checks to ensure the LF behavior is used everywhere, if that's what we want to align on. (I'll make sure we track this in an issue before this is merged.)
andreubotella
pushed a commit
to andreubotella/html
that referenced
this pull request
May 3, 2021
This was referenced May 3, 2021
|
WPT PR: web-platform-tests/wpt#28798 Browser bugs:
|
domenic
reviewed
May 5, 2021
domenic
approved these changes
May 6, 2021
andreubotella
pushed a commit
to andreubotella/html
that referenced
this pull request
May 19, 2021
Complements whatwg#6287 and whatwg#6624. Fixes whatwg#6647. See also whatwg#6662 for further cleanup on the textarea data model.
3 tasks
annevk
pushed a commit
to web-platform-tests/wpt
that referenced
this pull request
May 20, 2021
annevk
pushed a commit
that referenced
this pull request
May 20, 2021
User agents normalize newlines when serializing form data to text/plain, application/x-www-form-urlencoded, and multipart/form-data. (This can be observed through FormData or the formdata event.) This additionally changes the input passed to the application/x-www-form-urlencoded and text/plain serializers to be a list of name-value pairs, where the values are always strings rather than potentially File objects. Tests: web-platform-tests/wpt#26740. Follow-up: #6624 & #6697. Closes #6247. Helps with whatwg/url#562.
annevk
pushed a commit
that referenced
this pull request
May 20, 2021
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this pull request
May 27, 2021
… constructing the entry list, a=testonly Automatic update from web-platform-tests HTML: no newline normalization when constructing the entry list For whatwg/html#6624 and whatwg/html#6697. -- wpt-commits: a35aa4089a7498dd4e107828c0925823fe512c97 wpt-pr: 28798
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this pull request
May 27, 2021
… constructing the entry list, a=testonly Automatic update from web-platform-tests HTML: no newline normalization when constructing the entry list For whatwg/html#6624 and whatwg/html#6697. -- wpt-commits: a35aa4089a7498dd4e107828c0925823fe512c97 wpt-pr: 28798
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this pull request
May 29, 2021
… constructing the entry list, a=testonly Automatic update from web-platform-tests HTML: no newline normalization when constructing the entry list For whatwg/html#6624 and whatwg/html#6697. -- wpt-commits: a35aa4089a7498dd4e107828c0925823fe512c97 wpt-pr: 28798
FrankEnderman
pushed a commit
to FrankEnderman/cursemium
that referenced
this pull request
Oct 29, 2021
Chrome used to perform newline normalization in form payloads early into the form submission algorithm –in particular, during the entry list construction–, along with an additional normalization at the point of serializing the form data into `application/x-www-form-urlencoded` and `text/plain` form payloads. The early normalization was spec compliant – the late one wasn't, but was required because servers expected it. This change implements some recent changes in the HTML spec that have standardized this newline normalization behavior across browsers, removing the early normalization entirely and replacing it with a late normalization at the point of serializing, even for the `multipart/form-data` enctype. This change does not affect the submitted form payload for normal user-triggered form submissions. It only changes how form entry lists are inspected from Javascript using the `FormData` API and the `formdata` event, and how form entries added from Javascript are serialized (by fetching with a `FormData` body, or by modifying a form submission through form-associated custom elements or through the `formdata` event). As such, this change is implemented behind a default-on `LateFormNewlineNormalization` feature flag. This change implements the following HTML spec PRs: whatwg/html#6287 whatwg/html#6624 whatwg/html#6697 See also: https://blog.whatwg.org/newline-normalizations-in-form-submission Intent to Ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/XULXQrbFznw Fixed: 1167095 Change-Id: I0a28369aefe052c413a427733ef33d70988a13c1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3226394 Reviewed-by: Kent Tamura <tkent@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Kent Tamura <tkent@chromium.org> Cr-Commit-Position: refs/heads/main@{#936197}
mjfroman
pushed a commit
to mjfroman/moz-libwebrtc-third-party
that referenced
this pull request
Oct 14, 2022
Chrome used to perform newline normalization in form payloads early into the form submission algorithm –in particular, during the entry list construction–, along with an additional normalization at the point of serializing the form data into `application/x-www-form-urlencoded` and `text/plain` form payloads. The early normalization was spec compliant – the late one wasn't, but was required because servers expected it. This change implements some recent changes in the HTML spec that have standardized this newline normalization behavior across browsers, removing the early normalization entirely and replacing it with a late normalization at the point of serializing, even for the `multipart/form-data` enctype. This change does not affect the submitted form payload for normal user-triggered form submissions. It only changes how form entry lists are inspected from Javascript using the `FormData` API and the `formdata` event, and how form entries added from Javascript are serialized (by fetching with a `FormData` body, or by modifying a form submission through form-associated custom elements or through the `formdata` event). As such, this change is implemented behind a default-on `LateFormNewlineNormalization` feature flag. This change implements the following HTML spec PRs: whatwg/html#6287 whatwg/html#6624 whatwg/html#6697 See also: https://blog.whatwg.org/newline-normalizations-in-form-submission Intent to Ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/XULXQrbFznw Fixed: 1167095 Change-Id: I0a28369aefe052c413a427733ef33d70988a13c1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3226394 Reviewed-by: Kent Tamura <tkent@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Kent Tamura <tkent@chromium.org> Cr-Commit-Position: refs/heads/main@{#936197} NOKEYCHECK=True GitOrigin-RevId: 3a41107f23310a86c7fa4557be14e90b867baa01
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Tests: web-platform-tests/wpt#28798.
Complements #6287.
Fixes #6469.
/form-control-infrastructure.html ( diff )