Thanks for the report. That's indeed a misbehavior. The reason is that browsers consider the first submit button in the form the default one. And we need to make the other two buttons submit buttons as well to make the import process work without JavaScript. There are some workarounds for this behavior: https://stackoverflow.com/questions/925334/how-is-the-default-submit-button-on-an-html-form-determined.

I realized this is technically a regression, caused by the changes done via https://gerrit.wikimedia.org/r/519236 in June. Before, pressing enter probably worked. Unfortunately the patch doesn't explain why the change was made. @Andrew-WMDE, are you able to provide more info?

In T232810#5522929, @thiemowmde wrote:

I realized this is technically a regression, caused by the changes done via https://gerrit.wikimedia.org/r/519236 in June. Before, pressing enter probably worked. Unfortunately the patch doesn't explain why the change was made. @Andrew-WMDE, are you able to provide more info?

I think this was related to T230983: Edit summary is blanked when navigating through file importer preview pages. Now I wonder if both problems can be addressed without using JS to do magic in the background ....

The only hacks I can think of at the moment are:

• Have a JavaScript event handler listen for the enter key, and make it click the correct button.
• Some onfocus JavaScript that removes the type="submit" from the other buttons when the summary line is focussed.
• Arrange the HTML so the primary submit button appears first, and use CSS to re-arrange the buttons visually.
• Flip the form upside down.
• Ask for a summary in a separate, later step.
• …?

I just looked briefly into this and the other ticket T230983. To summarize the issue here again:

• At the beginning we had a form for each button that could be submitted separately.
  • In that scenario hitting enter in the summary field submitted the form to the next step of transferring the file.
  • Having mutliple forms though lead to the issue where we lose the contents of the summary field when someone wants to change the title. See T230983
• We fixed that issue by putting everything in one form so the summary is dragged along and that lead to this issue.

Assuming that we want to avoid data loss for non js users, there's no real alternative to having one form expect the summary in a second step. But that would also work with one form. So lets just say we keep the one form and try to find solutions for that. This solution also makes sure we at least do not lose any data entered by the user.

I could not think of other ideas then the ones mentioned by @thiemowmde above. So lets try to dive into the options.

Use JS to trigger submit when the focus is in the summary field

• (+) very easy to implement
• (-) won't solve the issue for non js users

Arrange the HTML so that the primary submit button comes first (but move it down again with CSS)

• (+) could be relatively easy to implement
• (-) very ugly solution
• (-) probably confuses screen readers

Flip the form upside down

• (+) easy to implement
• (-) probably confusing and not the usual workflow in MediaWiki

Ask for the summary in a second step

• (+) least hacky solution
• (-) most complicated to implement
• (-) people could be annoyed by such an "additional step"

I personally slightly prefer the JS only solution but maybe mostly, because it's very easy to implement.

Change 596401 had a related patch set uploaded (by WMDE-Fisch; owner: WMDE-Fisch):
[mediawiki/extensions/FileImporter@master] [WIP] Submit the from when hitting return in the summary

https://gerrit.wikimedia.org/r/596401

Change 596401 merged by jenkins-bot:
[mediawiki/extensions/FileImporter@master] Submit the form when hitting return in the summary

https://gerrit.wikimedia.org/r/596401