A button ripple effect appears again after a dialog is closed

[Eddygn]

Bug, feature request, or proposal:

A bug.

What is the expected behavior?

The ripple darkening effect shouldn't appear on a button after a dialog is closed.

What is the current behavior?

A ripple / CSS effect appears on the 'invoking' button again after the dialog is closed. Should be only one one animation cycle when the button is pressed.

What are the steps to reproduce?

From:
https://material.angular.io/components/dialog/overview

On:
Firefox 56.0.2
Chrome 61.0.3163.100

Pressing the "Pick one" button, the ripple effect is played and the dialog is opened, then closing the dialog in any way return the effect on the button.

https://i.imgur.com/oOmbAmS.gif

What is the use-case or motivation for changing an existing behavior?

It's visually 'bugged'

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

It appears in both local build
Angular 5
Material 5.0.0-rc0

And with a refreshed documentation / example page

Is there anything else we should know?

[jelbourn]

What you're seeing is the focus state for the button. It is normally supposed to only show when focus came from a keyboard interaction, but here it is happening when the triggering action is a mouse event.

[crisbeto]

@jelbourn showing it both for keyboard and programmatic focus was intentional, otherwise restoring focus from dialogs or sidenavs won't be visible. IMO program and keyboard focus should behave the same, otherwise users won't be able to see where focus is if we move it for them. It's different for mouse since people would already be following the cursor when they moved focus.

[devversion]

@jelbourn I think there are two solutions here:

• Focus properly from the dialog, drawer using the FocusMonitor#focusVia. This involves a way of detecting the origin type that opened the dialog, drawer (hard to do right now)

• Only show the focus styles for keyboard users (like we do with the checkbox, radio, etc. right now).

I chatted with @crisbeto about this and we think that solution 2) can be problematic for users with keyboard. The dialog, drawer will just restore focus using program and there won't be any focus indicator for keyboard users at all.

A better solution would be just keeping it as it is and prioritizing accessibility over the UX here. If we go that way I'll update the checkbox, radio, slide-toggle to also show the focus indicators for program.

[mmalerba]

What about adding an optional openedVia argument to the open method on these components. If its not specified we assume it was keyboard, if it is specified we just use whatever they gave us. I like this better because:

1. It doesn't affect other situations where the components may be program-focused
2. Users can just use the FocusMonitor and pass the needed info along if its important to them

[jelbourn]

I was thinking we could show the focus indicator whenever the dialog open action or the dialog closing action came from the keyboard.

[devversion]

We can also do it like @mmalerba described. This way we still give developers the flexibility to control whether the "original" element should have a focus indicator or not, but accessibility is prioritized by default.

For the dialog close action, I don't think there is an easy way to detect whether it came from the keyboard or not. In theory we could add a new option to the close() method and also register the FocusMonitor on the matDialogClose directive. But I'm not sure about that, it feels a bit too complicated for the developers in the end.