Re: [blink-dev] Intent to Ship: Late newline normalization in form submission

2021-10-24 Thread TAMURA, Kent 
LGTM3.


On Fri, Oct 22, 2021 at 8:05 PM Manuel Rego Casasnovas 
wrote:

> LGTM2
>
> On 22/10/2021 12:58, Daniel Bratell wrote:
> > 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
> >>
> >> On Friday, October 22, 2021 at 12:30:33 PM UTC+2 Daniel Bratell wrote:
> >>
> >> 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
> >>
> >> On 2021-10-21 23:45, Mason Freed wrote:
> >>>
> >>>
> >>> 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
> >>> <
> https://bugs.chromium.org/p/chromium/issues/list?q=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
> >>> <
> 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
> >>> .
> >>> --
> >>>

Re: [blink-dev] Intent to Ship: Late newline normalization in form submission

2021-10-22 Thread Andreu Botella 
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:

> 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
> On 2021-10-21 23:45, Mason Freed wrote:
>
> 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 
> .
>
> -- 
> 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
>  
> 
> .
>
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/992291b7-0047-4982-a9b9-797922eb3a64n%40chromium.org.

Re: [blink-dev] Intent to Ship: Late newline normalization in form submission

2021-10-22 Thread Manuel Rego Casasnovas 
LGTM2

On 22/10/2021 12:58, Daniel Bratell wrote:
> 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
>>
>> On Friday, October 22, 2021 at 12:30:33 PM UTC+2 Daniel Bratell wrote:
>>
>> 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
>>
>> On 2021-10-21 23:45, Mason Freed wrote:
>>>
>>>
>>> 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
>>> .
>>> -- 
>>> 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%2BmxZ0ksshLy0SG

Re: [blink-dev] Intent to Ship: Late newline normalization in form submission

2021-10-22 Thread Daniel Bratell 

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

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

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

On 2021-10-21 23:45, Mason Freed wrote:



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
.
-- 
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

.




--
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+unsubscr...@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.

Re: [blink-dev] Intent to Ship: Late newline normalization in form submission

2021-10-22 Thread Daniel Bratell 

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

On 2021-10-21 23:45, Mason Freed wrote:



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 
.

--
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+unsubscr...@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 
.


--
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/93d2eeb2-ad25-38fc-35b5-b12e5c7be90d%40gmail.com.

[blink-dev] Intent to Ship: Late newline normalization in form submission

2021-10-21 Thread Mason Freed 
Contact emailsand...@andreubotella.com, mas...@chromium.org

ExplainerNone

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 componentBlink


Search tagsnormalization
, html
, forms
, newline
, FormData


TAG review

TAG review statusNot 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 bughttps://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
.

-- 
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+unsubscr...@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.