some early ideas that we might want to consider:

1. separate the interaction between focusing/clicking the field, and clicking/tapping the chevron icon. focusing the field does not open the menu as long as you don't start typing. click/tap on the chevron opens the menu with suggested types
   
2. keep the same interaction for both focus and click/tap on the chevron icon.
   
3. remove the chevron icon
   

another observation from the usability study: one participant typed very fast the input type "string" and then moved to the next input field via keyboard tab navigation. as a result they did not select the result the item "String" from the menu leaving the selection invalid.

play/open the gif below as a reproduction of this behaviour

by opening the menu by default when the ZObjectSelector is focused could help minimize this edge case.

clicking on the chevron, and focusing on the lookup field is the same unique event.

The chevron is added as an end-icon attribute that's passed to the TextInput component (child of Lookup component)
https://doc.wikimedia.org/codex/latest/components/demos/text-input.html#with-icons

Currently, the TextInput can add icons at the start or at the end of the field, but does not listen to clicks on them, so we cannot react to those events to make the field focus when clicking the chevron. Also, currently we cannot display the suggestions when clicking the chevron, so I would simply remove it or change it for another icon that does not make the user think that this component might work as a dropdown selector.

In T350683#9326672, @gengh wrote:

I would simply remove it or change it for another icon that does not make the user think that this component might work as a dropdown selector.

agreed! we could remove the chevron, but then i'm unsure if we might loose the visual feedforward that could help function creators separate a text input from a lookup/select. without the chevron icon they would have to rely only on the placeholder text to discern the two input/actions, e.g. "Enter label" vs. "Select type".

alternatively we could opt for cdxIconSearch set as end-icon with the icon fill set to color-placeholder. hopefully by making the icon the same color as the placeholder text it will not prompt function creators to click/tap on it.

if we opt for the cdxIconSearch option i'm also wondering if the placeholder text should be changed. right now it says "Select type" but if we display a magnifying glass i would suggest to go for "Search type". Moreover, given that the lookup is a search and select, we could add "..." at the end of the placeholder text "Search type..." given that ellipses are commonly used to mark an additional action needed on the user end, in our case what is needed beside searching is the action of selecting a result from the menu.

last but not least, if we would want to also better visually separate a filled in text input vs a lookup field we could also set the clearable prop when after a lookup selection.

In summary, these are the possible options:

1. hide the chevron icon
2. use cdxIconSearch
   • a. (optional) change placeholder text to "Search type..."
   • b. (optional) make the lookup field clearable if filled in

what you think @gengh? i would suggest we go for 2b, or 2a if we encounter any unforeseen implementation complexity.

after a sync conversation with @gengh we decided to opt for the most simple approach, start learning, and iterate from there. the current issue is: "function creators click/tap on the chevron icon but nothing happens". so, we checked whether we can make that icon interactive, but it's currently not possible. so we're going to remove the icon to avoid confusing people.

moreover, in order to make sure that an entered lookup value is a valid entry we're going to:

1. auto select a value if the entered query is the same as a result item. e.g. function creator enters "string" but doesn't click/tap on the "String" menu item below to confirm/complete the selection
2. clear the lookup field if the entered query is a non-valid entry, e.g. function creator enters "word" and escape focus, but "word" is not an available type

We've not actually made this change, but a fair number of changes have been made to the object selector workflow since this was filed. Can we declare this Resolved at this point?

In T350683#9616223, @Jdforrester-WMF wrote:

We've not actually made this change, but a fair number of changes have been made to the object selector workflow since this was filed. Can we declare this Resolved at this point?

i would keep it open because the issue is still present. both when the lookup is empty, and when is (pre-)filled. on one side, the chevron is being helpful in giving a signifier to editors, but on the other it doesn't work as an affordance because when they click on it nothing happens.

wondering if we should scale this up to Codex? meaning, how might we make a lookup input, different from a text input? or should it be different at all?