Prevent submitting outer form when enter is pressed in Url/Unsplash plugin

[arturi]

Related: transloadit/uppy.io#51

Problem: when Uppy Dashboard is wrapped in an outer <form>, pressing enter on inputs inside Uppy submits that outer form, instead of confirming the input inside Uppy. This PR seems to resolve it in my tests.

Is there some use case where actual form and submit event would be better, does handling enter key not cut it?

[mifi]

Change LGTM!

Is there some use case where actual form and submit event would be better, does handling enter key not cut it?

At least on iOS, we need to wrap the input in a form in order to get the blue submit button on the bottom right of the on screen keyboard. Without a form it will just show a grey "Return" key. So that's one argument for wrapping in a form.

https://stackoverflow.com/questions/4864167/show-search-button-in-iphone-ipad-safari-keyboard/11254336#11254336

Another argument for using a form might be to improve accessibility - because a form has semantics, and everyone knows forms can be submitted with a standard submit action, while an input with an onKeyDown: if keyCode === 13, is not very semantic.

[Murderlon]

I'm also interested in trying out putting a form in Uppy. It might be error-prone to always think about adding preventDefault in places that need it.

[arturi]

I would be all for using <form> for semantics, the arguments against it are: you can’t wrap a form in a form in HTML, so if we use one in Uppy UI, it’s a requirement for devs to not place Uppy Dashboard in their own <form>.

Why you would want that?

1. Progressive enhancement. You have form with file input, then Uppy comes and replaces it with fancy UI. JS not loaded? Form still there. Although here we do just that https://uppy.io/examples/xhrupload/ and destroy the form before loading Uppy, so that should work.
2. Actual form with fields — name, surname, date of birth, etc, then comes “attach a photo”, then more fields. Could be a button that calls Dashboard modal, but if it's inline, many would want to place Dashboard inside the form then, and we have a conflict.

Example (I mean the drag-drop area this time):

[arturi]

Oh found this by @aduh95 that we use in the meta field editor (which I forgot about): #3113

And also got me thinking, what about custom inputs that we support in the meta editor? They will not have our stopPropagation/preventDefault and will submit the outer form?

[Murderlon]

And also got me thinking, what about custom inputs that we support in the meta editor? They will not have our stopPropagation/preventDefault and will submit the outer form?

I think in this case we control the "submit" button, right? People are only allowed to add fields.

[arturi]

I think in this case we control the "submit" button, right? People are only allowed to add fields.

Yes, but the current issue and PR is with the field, if you press enter in the field (input), without event.preventDefault(), the outer form submits?

[mifi]

let's go with form attribute then - best of both worlds

[arturi]

Yep, originally @aduh95's idea, already implemented in

uppy/packages/@uppy/dashboard/src/components/FileCard/index.jsx

Line 100 in db3d71b

form={this.form.id}

I will try to replicate this everywhere we have inputs with submits.

[arturi]

Superseded by #4283