Element: [Bug Report] Select element can't be filtered if down key isn't pressed beforehand

[Terrijoo]

Element UI version

2.2.1

OS/Browsers version

Version 64.0.3282.186 (64-Bit)

Vue version

2.5.13

Reproduction Link

https://jsfiddle.net/Terrijoo/d7L01ufv/

Steps to reproduce

Click into the first Input field, press "Tab" and try to type.

What is Expected?

The list pops up and it starts filtering.

What is actually happening?

You can't type in it at all, you need to explicitly press down beforehand to let the list pop up.

[wacky6]

Seems to be a regression in 2.2.1.

[wacky6]

Related to PR https://github.com/ElemeFE/element/pull/9857 and https://github.com/ElemeFE/element/pull/9894

@Seebiscuit @openks Could you guys take a look? Expected behavior is: https://jsfiddle.net/d7L01ufv/5/

[Seebiscuit]

I believe the behavior stems from this deletion

       handleFocus(event) {
         this.visible = true; // removed by #9894
         this.$emit('focus', event);
       },

Setting true to this.visible reveals the popper. Perhaps @openks or @leopoldthecoder can shed more light on the issue, and explain why this.visible was removed in that PR.

[openks]

according to #9821 the select or the input in select focus show not open the popper,
only select clicked or the input in select focused and the enter key pressed the popper show

[Terrijoo]

@openks Is there at least a possibility to make it optional, like an extra attribute? It can be very a very tedious work to fill a form with a lot of fields, if you tab through them and have to first press the down key everytime.

[openks]

The original select when you tab through is also only focused and you should press the enter key to show the options ,so i think it's ok
@Leopoldthecoder i don't know is it ok to add a extra attribute to control this situation? if it's ok mybe i can do it .

[Leopoldthecoder]

This actually is intended in 2.2.1. But since you brought it up, we may now discuss if it is reasonable.

Before 2.2.1, the dropdown shows when you focus the Select. This makes navigating or filling the forms easier, but causes #9821. Plus, the native <select> does not show its options on focus.

In 2.2.1, Select behaves just the opposite. So the pros and cons are turned.

I looked at select2 and selectize, turns out they don't agree on this matter as well.

@Terrijoo @wacky6 @Seebiscuit @openks so what's your opinion? Should we keep it as is or revert it to 2.2.0?

[openks]

i think we should keep it to make it like native <select>

[Terrijoo]

I'd say keep it as it is, but make it optional via attribute.

I'm thinking about the end customers that fill forms all day long and need to press enter/down to trigger the option list first.
Do that a few hundred times and it might get frustrating.

If you have it as an attribute, you can also avoid #9821 , since this is usually not an issue with the attribute filterable.
Example: Have a list of streets loaded from the server after chaning zipcode/city and street is next, so you just tab and start typing.

[wacky6]

I think we are at "unknown territory" here.

• Native select does not have filterable / remote-search feature. But if you focus/tab to it and type something, it will change to most-likely option.
• My guess on right-click on select is this kind of scenario is less frequent than tab + type.

I am +1 on @Terrijoo , adding an attribute to select to allow a mouse-less input (or make a sensible default when filterable or remote-search is used.

Might also consider to be intelligent: don't show dropdown when focused, but as soon as user types something, open the dropdown.

[Seebiscuit]

I agree with @Terrijoo, that simple select's behavior should be customizable via an attribute, and I agree with @wacky6's suggestions that filterable should be intelligent.

I can work on adding the attribute. And maybe make a separate PR for thefilterable case?

Does the name automatic-dropdown make sense for the attribute?

[wacky6]

@Leopoldthecoder What do you think? Do we need to consider remote-method usage? Intelligent or attribute, or both?

[Seebiscuit]

Thinking more about, I think filterable types should also have an automatic-dropdown attr. _Additionally_, if automatic-dropdown is null or false, keyDown should toggle the popper for filterable types

[Leopoldthecoder]

After #10042 we have automatic-dropdown.