Select component on a side drawer - escape key closes the drawer

[gtranter]

Bug, feature request, or proposal:

Bug?

What is the expected behavior?

When the select is open on a temporary side drawer, the escape key should close the select list, but not the side drawer.

What is the current behavior?

When the select is open on a temporary side drawer, the escape key will close the drawer as well as the select list.

What are the steps to reproduce?

https://stackblitz.com/edit/angular-dttmuf

1. Open the drawer using the button
2. Open the Select.
3. Press escape.

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

Angular 5.2.4, Angular Material 5.2.1

[julianobrasil]

The two components respond to escape key pressing... Have you tried to bind disableClose sidenav's input property to the openedChange output of the select? The docs says it emits when the panel opens. I suspect it also emits when it is closed though (and it's a small nit in the docs - I haven't tested it yet).

If it behaves as I think it does, you can disable the sidenav's closing actions when the select panel opens and reenable them again when the select panel closes.

EDIT: Yeah, I can confirm it works: https://stackblitz.com/edit/angular-sidenav-and-select

[gtranter]

That works nicely in a simple case like the stackblitz example, but unfortunately in my actual application the mat-select is in a custom component that is added to the mat-sidenav drawer. So the DOM containing the mat-select doesn't know about the mat-sidenav. I don't want to hack the components or write a service to patch in access between the two, and I don't know an easy way around that.

[julianobrasil]

No... in that case I cannot think of a more direct way than the ones you've already suggested above (personally, I'd go with the service).

To make it work without any work around, I think there should be a kind of stack behind the scenes to keep track of overlay's instances so that the closing actions would, optionally, affect just the one on top of the stack. I'm not sure there's something like this.

[gtranter]

Shouldn't the select list's handling of the esc key event just stop propagation? (Total guess - I have no idea how it's currently wired.)

[julianobrasil]

There should be a good reason for not doing it. Maybe someone from inside material team can actually give you an answer.

[jelbourn]

@crisbeto I vaguely recall either seeing a PR for this or talking about it

[crisbeto]

@jelbourn we talked about it. My idea was to move the OverlayKeyboardDispatcher out of cdk/overlay and to allow any component to subscribe to it. That way we can have the sidenav (and other components) not clash with others.

[stevenyxu]

I've been struggling with the same issue where any widget on a mat-sidenav (in our case, our equivalent internal component) cannot implement standard ESC keypress handing because OverlayKeyboardDispatcher owns it on capture phase. Cris and team, thank you for this excellent service, which elegantly solves an interesting problem, and I hope that we can address this too.

This was intentionally done in #9546 but I can't pick out exactly why. It's defensive in a sense, but in this case, I worry it may have been defensive to the point of being harmful. If someone is calling stopPropagation on an event, they need to own all the consequences of it including an overlay not being notified. It's how most event listeners work and makes stopPropagation a valuable tool to give events their intended consequences when listeners are nested.

Regarding the proposal to move OverlayKeyboardDispatcher out, it would be hard to scale this. In effect, we'd have to instruct everyone, including those who don't use overlays, to use this instead of (keydown.escape) and similar, which is onerous.

@crisbeto what do you think?