Intent to Ship: Late newline normalization in form submission

Mason Freed

unread,

Oct 21, 2021, 5:45:45 PM10/21/21

to blink-dev

Contact emails

and...@andreubotella.com, mas...@chromium.org

Explainer

None

Specification

https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#constructing-form-data-set

Design docs

https://blog.whatwg.org/newline-normalizations-in-form-submission

Summary

Before this change, newlines in form entries were normalized early in the form submission process (during the entry list construction), with an additional late normalization happening as the form payload was encoded with the application/x-www-form-urlencoded enctype. With this change, the early normalization is removed and the late normalization is extended to all enctypes.

Blink component

Blink

Search tags

normalization, html, forms, newline, FormData

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

While this is a change in behavior, it should only affect very corner case situations. And the fact that both WebKit and Gecko have shipped this behavior should also mitigate the compat risk. For more detail, see the discussions on the spec PR: https://github.com/whatwg/html/pull/6287 This is an interop-related change: prior to this feature launching in Chromium, the browsers differed on behavior. They will now be the same.

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: No signals

Debuggability

No DevTools support required. This feature can be debugged directly via Javascript.

Is this feature fully tested by web-platform-tests?

Yes

Flag name

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1167095

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5654547184746496

This intent message was generated by Chrome Platform Status.

Daniel Bratell

unread,

Oct 22, 2021, 6:30:33 AM10/22/21

to Mason Freed, blink-dev

LGTM1

If I understand correctly, this change would only be visible if someone programmatically creates form data in javascript with the FormData constructor, that data has non-CRLF newlines and the page in one way or another depend on the interim value having been normalized inside the FormData object before submit. I agree that this is an obscure case and the presence of other browsers with different behaviour makes this ok to ship.

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDhaRnX8dvv-UoR%2BmxZ0ksshLy0SGbx5Krk4wguf1B_r6A%40mail.gmail.com.

Daniel Bratell

unread,

Oct 22, 2021, 6:58:16 AM10/22/21

to Andreu Botella, blink-dev, mas...@chromium.org

Thanks for the clarification! My LGTM1 stands.

/Daniel

On 2021-10-22 12:51, Andreu Botella wrote:

Just to clarify: inspecting a FormData object isn't the only way to observe this change. If you call fetch() with a FormData body, have a form-associated custom element whose submission value is a FormData, or modify a form's entry list through the FormData object passed in the formdata event, before this change you could end up with unnormalized entries in the form payloads, since early normalization doesn't apply and the FormData methods don't normalize entries. Since late normalization happens at the point of encoding the form payload as the corresponding enctype, those cases will now be normalized. It's still an extremely obscure case, though.

Andreu

Manuel Rego Casasnovas

unread,

Oct 22, 2021, 7:05:52 AM10/22/21

to Daniel Bratell, Andreu Botella, blink-dev, mas...@chromium.org

LGTM2

>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>
>>>
>>>
>>> Search tags
>>>
>>> normalization
>>> <https://chromestatus.com/features#tags:normalization>, html
>>> <https://chromestatus.com/features#tags:html>, forms
>>> <https://chromestatus.com/features#tags:forms>, newline
>>> <https://chromestatus.com/features#tags:newline>, FormData
>>> <https://chromestatus.com/features#tags:FormData>

>>>
>>>
>>> TAG review
>>>
>>>
>>>
>>> TAG review status
>>>
>>> Not applicable
>>>
>>>
>>> Risks
>>>
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> While this is a change in behavior, it should only affect very
>>> corner case situations. And the fact that both WebKit and Gecko
>>> have shipped this behavior should also mitigate the compat risk.
>>> For more detail, see the discussions on the spec PR:
>>> https://github.com/whatwg/html/pull/6287 This is an
>>> interop-related change: prior to this feature launching in
>>> Chromium, the browsers differed on behavior. They will now be the
>>> same.
>>>
>>>
>>>
>>> Gecko: Shipped/Shipping
>>>
>>> WebKit: Shipped/Shipping
>>>
>>> Web developers: No signals
>>>
>>>
>>> Debuggability
>>>
>>> No DevTools support required. This feature can be debugged
>>> directly via Javascript.
>>>
>>>
>>>
>>> Is this feature fully tested by web-platform-tests

>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?

>>>
>>> Yes
>>>
>>>
>>> Flag name
>>>
>>>
>>>
>>> Requires code in //chrome?
>>>
>>> False
>>>
>>>
>>> Tracking bug
>>>
>>> https://crbug.com/1167095
>>>
>>>
>>> Estimated milestones
>>>
>>> No milestones specified
>>>
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://chromestatus.com/feature/5654547184746496
>>>
>>> This intent message was generated by Chrome Platform Status

>>> <https://www.chromestatus.com/>.

>>> --
>>> You received this message because you are subscribed to the
>>> Google Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to blink-dev+...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDhaRnX8dvv-UoR%2BmxZ0ksshLy0SGbx5Krk4wguf1B_r6A%40mail.gmail.com

>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDhaRnX8dvv-UoR%2BmxZ0ksshLy0SGbx5Krk4wguf1B_r6A%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ed785631-8d22-a1d7-9e57-d798a2564342%40gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ed785631-8d22-a1d7-9e57-d798a2564342%40gmail.com?utm_medium=email&utm_source=footer>.

Andreu Botella

unread,

Oct 23, 2021, 12:23:28 AM10/23/21

to blink-dev, Daniel Bratell, mas...@chromium.org

Just to clarify: inspecting a FormData object isn't the only way to observe this change. If you call fetch() with a FormData body, have a form-associated custom element whose submission value is a FormData, or modify a form's entry list through the FormData object passed in the formdata event, before this change you could end up with unnormalized entries in the form payloads, since early normalization doesn't apply and the FormData methods don't normalize entries. Since late normalization happens at the point of encoding the form payload as the corresponding enctype, those cases will now be normalized. It's still an extremely obscure case, though.

Andreu

On Friday, October 22, 2021 at 12:30:33 PM UTC+2 Daniel Bratell wrote:

TAMURA, Kent

unread,

Oct 25, 2021, 1:37:36 AM10/25/21

to mas...@chromium.org, blink-dev, Daniel Bratell, Andreu Botella, Manuel Rego Casasnovas

LGTM3.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4599b155-8ebc-715c-ea76-5023dd7fe86f%40igalia.com.