Maybe a fallout of T415288?

Change #1270874 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/CommunityConfiguration@master] fix(NamespacesControl): avoid wiping chips when selecting a menu item

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

Change #1270877 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[design/codex@main] [DNM][MRE] Minimum reproducible example: wrong menu expansion with initial selection

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

I debugged the issue a bit and realized that in 1233740 we changed (unintentionally?) the initial namespaces value selection from being numbers to being "formatted" strings. However the value for menu items and chips remained to be a number. Hence, when selecting a menu item after filtering, the updated received by onNamespacesUpdated is an array of mixed elements. I haven't debugged what happens after that so the input is wiped, but sending an update to jsonform lib that does not respect the control backing data type is already wrong by design. Also can make element === , == comparisons fail. cc @EMcFarland-WMF

After fixing that (1270874) the model value is properly handled by CdxMultiselectLookup, no wiping occurs. However, another issue appears, this time seems more to be on the Codex side. Steps to reproduce with 1270874 pulled are the same as the main scenario of this task, however in this case: What happens? The menu remains expanded. What should have happened instead? The menu should be closed (?)

For facilitating the debugging of this I've prepared a minimum reproducible example in Codex sandbox, (1270877). I haven't had the time to dig this deeper but it seems the onInputFocus handler is being triggered for some reason on menu items selection and chip input removal (these are updated to the "selection"). cc @AnneT since you wrote this component and sure have more context. Any hint is appreciated :)

Thank you for debugging this, Sergio! I am taking a look now.

hey @Sgs and @EMcFarland-WMF, thanks for the clear debugging steps. The difference between the MultiselectInputDemo that @Sgs updated to include initial items and the MultiselectLookupWithInitialSelection demo on the docs site is that the latter clears the menu items when the input value is empty:

function onInput( value ) {
    if ( value ) {
        menuItems.value = vegetableItems.filter( ( item ) => item.label.includes( value ) );
    } else {
        menuItems.value = [];
    }
}

It looks like your component, when the input value is empty, resets the menu items to a set of namespaces. This is what the component considers "suggestions", as demoed here. This was the intended behavior - basically show the menu any time there are menu items, to make it easy for users to select multiple items.

If you don't want the menu to remain open after selection, you could only show the namespaces initially when the component mounts. Once an item is selected, you could clear the menu items instead of resetting it to the namespaces.

Hope this helps - let me know if I'm misunderstanding your use case. I'll also say that MultiselectLookup is a complex component in terms of UX and there is certainly room for improvement, so please feel free to open a task on the Codex board if you have suggestions.

Thanks, Anne! This was really helpful. I think showing the names initially only when the component mounts, and then clearing the menu when the item is selected, would make sense. I will try that and reach out with any further questions.

In T422017#11820197, @AnneT wrote:

It looks like your component, when the input value is empty, resets the menu items to a set of namespaces. This is what the component considers "suggestions", as demoed here. This was the intended behavior - basically show the menu any time there are menu items, to make it easy for users to select multiple items.

If you don't want the menu to remain open after selection, you could only show the namespaces initially when the component mounts. Once an item is selected, you could clear the menu items instead of resetting it to the namespaces.

Thanks for the feedback. There were a couple of wrong things in our usage of MultiselectLookup which were at the culprit of the wiping problem (1277498, 1270874). With those fixed, I gave a try to your suggestion of emptying menu items on item selection and it works for menu item additions but then the "suggestions" behavior is broken, the menu won't show with pre-filled results on focus events. This is quite edgy compared to the prior state of the NamespacesControl component so not high priority. But ideally we would like to fix and/or understand what's happening here.

Hope this helps - let me know if I'm misunderstanding your use case. I'll also say that MultiselectLookup is a complex component in terms of UX and there is certainly room for improvement, so please feel free to open a task on the Codex board if you have suggestions.

I'm not yet sure if I should file a task for the following behaviours. Observed weird issues in MultiselectLookup with suggestions (see example in 1270877):

1. On the first focus interaction with the field, if provided with suggestions, the menu will expand and show them all (no prior user input). However after another interaction, eg: input typing or menu selection, then the focus won't show again any suggestions

2. When typing and getting filtered results and after removing the query, the full list of suggestions is not displayed again

3. When typing a matching query and then deleting it using keyboard selection and delete key they query results will stay in the menu and be shown on the next focus (maybe sub-case of 2)

If these seem off also for you @AnneT I'll file a Codex bug report or improvement task.

Change #1270874 merged by jenkins-bot:

[mediawiki/extensions/CommunityConfiguration@master] fix(NamespacesControl): avoid wiping chips on menu item select

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

Change #1282418 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] [PoC] Improve UX of MultiselectLookup with suggestions demo

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

Hey @Sgs, I think this is more an issue of Codex not documenting how to handle menu items, instead of a bug in the component.

On the first focus interaction with the field, if provided with suggestions, the menu will expand and show them all (no prior user input). However after another interaction, eg: input typing or menu selection, then the focus won't show again any suggestions

This happens because in the code, on input, if there is an input value, the menu items are set to items that match that search query. If there is no input, nothing happens, so the menu items are never reset to the suggestions.

When typing and getting filtered results and after removing the query, the full list of suggestions is not displayed again

Same thing; the menu items were never reset to the suggestions.

When typing a matching query and then deleting it using keyboard selection and delete key they query results will stay in the menu and be shown on the next focus (maybe sub-case of 2)

This one is the closest to a bug IMO, but I think it can be fixed via the implementation (and perhaps better documenting how this should be done). This is what's happening:

1. You type "napa", the menu items are filtered down to just "napa cabbage"
2. You delete the search term all at once. The input handler sees that there is no input value and therefore does nothing.
3. The menu items are still just "napa cabbage"

This can also be fixed by resetting the menu items when the input value is empty.

If you only wanted to show the suggestions initially as discussed above, you could reset the menu items to an empty array instead. But basically, we're relying on the feature code to handle managing the menu items. The MultiselectLookup simply responds to a combination of user action and whether there are menu items to show.

I pushed a patch on top of yours demonstrating this - let me know if it makes sense or if I'm missing anything!

Checked the fix for "adding a new chip to NamespacesControl sometimes wipes existing chips" issue in enwiki beta - the issue is fixed.

Notes:

• there are couple of issues with validating input into the forms (unrelated to mentioned in the comments above).
  • suggestion search is case sensitive

Special:CommunityConfigurtion/HelpPanel Namespaces fields give "No results found" if a search for a valid namespace starts a lower case letter.
e.g. when typing help, no suggestions will be found:

• not-found matches are still accepted (will silently fail)

Typing my own infobox in on Special:CommunityConfiguration/GrowthSuggestedEdits in the Infobox templates field, will be accepted and displayed as a valid template :

Hi @Etonkovidova, thank you for QAing this. I thought that for Special:CommunityConfiguration/GrowthSuggestedEdits, we wanted the user to be able to enter custom input. See https://phabricator.wikimedia.org/T398428#11619504. Please let me know if I am missing something.

Change #1283709 had a related patch set uploaded (by EMcFarland; author: EMcFarland):

[mediawiki/extensions/CommunityConfiguration@master] [WIP] [DNM] NamespacesControl: Make filterSearchQuery case insensitive

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

Change #1283709 merged by jenkins-bot:

[mediawiki/extensions/CommunityConfiguration@master] NamespacesControl: Make filterSearchQuery case insensitive

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

Although I don't think that adding templates from different wikis will actually work.

Hi Elena! I know this task is resolved, but I discussed our conversation with Martin in a meeting and wanted to follow up with you. I was wrong, you were right. Martin explained that there have been cases when Czech Wiki users had copied and pasted information from English Wiki templates, however, they would not be able to directly link from Czech Wikipedia to a template in English Wikipedia. My mistake.