I just tested what is happening in selectors for Item values right now on Item pages: nothing in both cases.
@Erdinc_Ciftci_WMDE @Sarai-WMDE: Thoughts?

I'd love to hear thoughts from @Nikki as well.

We are looking at this together now in our 1:1 with Sarai, @Lydia_Pintscher

We agree that the desired behavior in both cases is no response.

In 1, Enter shouldn't do anything because the user can go to the next area by just using the 'tab'.,

In 2, Enter again shouldn't do anything, so no response again, but when the user presses 'tab' and goes to the next interactive element the 'no result' menu should close, that seems to be the default behavior of the component in WiKit, can we have it here too?

We are not sure any change is required in WiKit because it's the application logic on the page.

Ok great. Thank you!
Then let's go with that.

In T305359#7828969, @Lydia_Pintscher wrote:

I just tested what is happening in selectors for Item values right now on Item pages: nothing in both cases.
@Erdinc_Ciftci_WMDE @Sarai-WMDE: Thoughts?

I'd love to hear thoughts from @Nikki as well.

I never got a notification for this, sorry. :(

If I've understood the description correctly, how it behaves on item pages for you isn't how it behaves for me. When selecting an item as the value of a statement, the first enter selects a search result, the second submits the edit. If there's no results, the first enter can't select a search result, which means the state can't change, so then the second enter behaves the same as the first and still can't select a search result.

In T305359#7837689, @Erdinc_Ciftci_WMDE wrote:

In 1, Enter shouldn't do anything because the user can go to the next area by just using the 'tab'.,

I don't follow the logic there. The normal behaviour of enter in a form is to activate or accept the currently selected element (e.g. activate a button; accept the currently highlighted option for a <select> or in the list of auto-complete suggestions for an <input> and close the dropdown; open and close date or colour selectors), or to submit the form. What does that have to do with moving to the next field?

In T305359#7837689, @Erdinc_Ciftci_WMDE wrote:

In 1, Enter shouldn't do anything because the user can go to the next area by just using the 'tab'.,

I don't follow the logic there. The normal behaviour of enter in a form is to activate or accept the currently selected element (e.g. activate a button; accept the currently highlighted option for a <select> or in the list of auto-complete suggestions for an <input> and close the dropdown; open and close date or colour selectors), or to submit the form. What does that have to do with moving to the next field?

Hey @Nikki 👋🏻 Just to clarify: In his message, @Erdinc_Ciftci_WMDE is not contradicting the normal behavior of Enter in forms that you're so rightfully describing, neither is he stating that focus should move to the next interactive element if Enter is pressed. He's just referring to the fact that, when he tried to reproduce the first scenario (pressing Enter again once an option has been selected), his focus was moving to a new field for some reason, which of course shouldn't happen. I'm sorry about the misunderstanding.

When selecting an item as the value of a statement, the first enter selects a search result, the second submits the edit. If there's no results, the first enter can't select a search result, which means the state can't change, so then the second enter behaves the same as the first and still can't select a search result.

That's exactly the behavior of lookups and other inputs on item pages, indeed. The behaviors that @Michael is referring to, though, have been observed in an app that's currently being developed using our in-house design system. The page mainly contains a form with 3/4 fields, and we were trying to stop the whole form from submitting itself when Enter is pressed to make a selection. Michael also noticed a couple of cases for which the behavior of enter wasn't defined, and that's what Erdi and myself tried to help out with:

1. Pressing "Enter" after an option has been selected and the Lookup is still focused? > Here one would usually throw a submit event (I guess this is what happens on item pages), but since we're handling a whole form, we guessed that information should be preserved and stay visible on the UI, therefore the "do nothing" indication.

2. Pressing "Enter" after typing something for which there is no option available ("no-results" message is shown)? > Same as above, and as you describe: since there are no results to be selected, Enter would do nothing. Here Erdi was also suggesting an improvement in the context of this WIP form: if users tab away from an active lookup (input that displays a menu) then the menu should close.

Task Breakdown Notes:

• Do we want to avoid all scenarios where enter submits the form? According to @Erdinc_Ciftci_WMDE the preferred way to submit the form would be by tabbing to the submit button and pressing enter. However, submitting upon enter keypress event emitted from the focused field is not out of the question, as long as the value was already selected in the particular case of lookup fields.
• Leave the decision to the implementer until we know more about the potential implementation possibilities?

Possible plan of action:

1. Investigate when and how the submit event is triggered, and the focus moves on to other validatable fields
2. Prevent a submit event from being fired in each input wrapper components or the item lookup component, before any option selected.
   • When there are no results, the menu stays open, otherwise a selection is made or the text remains, the menu closes and in any case focus remains on the input.
3. Ensure that the submit functionality is maintained for other cases, depending on chosen implantation.

Investigating submit with pressing enter

tl;dr: We can go with 'enter' submitting the form, as long as it does the inline error validation anyway.

As @ItamarWMDE wrote down I suggested sending the data with submit button instead of pressing enter key but after @Lucas_Werkmeister_WMDE brought to attention that editors have a different way of doing things I had to look at it again. When I tried different parts of Wikidata I realized even the areas that have multiple entries like item term boxes submit all the data with the just enter key.

I think at the end of the day keeping the experience consistent on different parts can avoid possible pain points for our editors, so we can keep this behavior as it's by also doing our inline validation, which hopefully avoids submitting by mistake. So we can go ahead and implement it as it works in other parts of Wikidata.

Uploaded one possible approach at https://github.com/wmde/wikit/pull/590.

Now waiting for Wikit prerelease: https://github.com/wmde/wikit/pull/596

https://github.com/wmde/new-lexeme-special-page/pull/219

WikibaseLexeme.git still needs an updated, that can be included in the patch for T308654.