bug(mat-select): Select looses focus when activating one of children via mouse

[Akxe]

Reproduction

Use StackBlitz to reproduce your issue: https://stackblitz.com/edit/components-issue-fjmby9 (watch red/green boolean in toolbar)

Steps to reproduce:

1. Have mat-select with mat-options
2. Click on one of the options
   a. option gets de-selected

Expected Behavior

When clicking on options of select, the select gets de-focused.

Actual Behavior

When select is opened, its focus status is locked to true, until it gets closed. Upon closing the focus should be decided, whenever the focus is to be kept or not.

Clicking outside of options defocuses, esc keeps focus on select. This is the same as native select and how it works in mat-select now.

Environment

• Angular: 10.0.3
• CDK/Material: 10.0.1
• Browser(s): Chrome
• Operating System (e.g. Windows, macOS, Ubuntu): WIndows

[crisbeto]

I'm not sure I follow what the issue is here. Is the expected behavior that focus doesn't get returned when you select something with the mouse?

[Akxe]

When you press mouse button on option and wait the select will be de-focused, that should not be the case, as the options are sub part of select.

Compare this behavior to native select to see the difference (long press is necessary to visualise it clearly, but any mouse press will trigger this effect).

[crisbeto]

I don't think there's much we can do about that. The problem is that the browser moves focus on mousedown and we can't move focus back until mouseup or we risk interrupting the click sequence.

[Akxe]

I thought so and so I came up with two possible solution:

• The blur event will not be fired while the option is open, thus keeping the focus.
• Make options not focusable and combat all that comes with it... Bit too complicated but possible non the less.

I think the first option is not that hard to implement and will comply with native select.

[crisbeto]

Where would we bind the blur event? It can't be on the select itself, because it would basically be the same as if we restored focus inside mousedown.

[Akxe]

It would be something along these lines:

combineLatest ([
  zip ([
    fromEvent (selectElement, 'focus').pipe(mapTo(true)),
    fromEvent (selectElement, 'blur').pipe(mapTo(false)),
  ]),
  this.optionsOpened$
]).pipe(
  map(([focused, opened]) => opened || focused),
)

[Akxe]

Does this still need triage or just solution?

[crisbeto]

This is what I was referring to above about moving focus back before mouseup. I believe that if we do it too early (before mouseup), it'll interrupt the click event on the option and won't allow it to be selected.

[Akxe]

I suggest that we fake the focus on select. If we don't bind focus/blur directly on the element, we could manipulate when it actually is selected.

Then we should make sure that FocusManager is correctly faked, and that docs says something about focus within not working with select in this case.

---

For the second option, what if the actual elements (for Aria and tabbing) would be inside mat-select and only mimicked their state to the overaly?

[crisbeto]

My concern is that this seems like a lot of trouble to go through for something that only happens for a split second and generally doesn't have any visible effect in the UI. What use case are we trying to solve in the first place?

[Akxe]

I want to know if any of my inputs are focused on. I would denounce that focused$ observable, but if the user clicks on one of the options and hold the mouse the select will trigger blur and my inputs will then hide.

See images in #19990

[crisbeto]

Makes sense, but I think that we'd have to talk about the trade-offs with supporting this case. For what it's worth, mat-select has a focused property that will stay true as long as the panel is open. Another approach could be to monitor focus on mat-option as well.