Re: [whatwg/url] Web reality: Filenames should be newline-normalized in urlencoded (#562)

Around the time of the latest post so far in this thread, @annevk and I reasoned on IRC that it was fine for "constructing the entry list" to depend on the form's enctype (with `new FormData(formEl)` counting as `multipart/form-data`) because there wasn't any API that could, say, serialize a `FormData` as `urlencoded` or turn a `URLSearchParams` into a `FormData`.

Unfortunately, when I was working on a PR, I noticed two APIs that make it possible for an entry list constructed as `urlencoded` or `text/plain` to reach contexts that would expect an entry list constructed as `multipart/form-data`:

- In a form-associated custom element, if the [submission value](https://html.spec.whatwg.org/#face-submission-value) is a `FormData` object, [its entries get appended to the form's entries](https://html.spec.whatwg.org/#face-entry-construction), without normalization ([note that Chrome currently gets this wrong](https://bugs.chromium.org/p/chromium/issues/detail?id=1158349)). If the `FormData` object was constructed from a `<form>` element, and the FACE is associated to a form with `urlencoded` or `text/plain` enctype, we have a problem.
- The [`formdata`](https://html.spec.whatwg.org/#constructing-form-data-set:event-formdata) event is fired in the "constructing the entry list" algorithm, which passes a `FormData` object to the event listener which can be used not only to query but to update the entry list.

I'll be adding tests to web-platform-tests/wpt#26740 to figure out what browsers do in each case.

Also, this issue should be probably moved to HTML.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/562#issuecomment-744453348