<md-button>: cancelling button tap/click does not remove :focus style

[mwilc0x]

Hi, first thanks for this project, great stuff.

Noticing this behavior with md-buttons.. please let me know if this is expected behavior or if an enhancement that might create a better UX.

If user clicks a button but drags their finger/cursor off the button and cancels the tap/click, the :focus style is not removed from the button. So like in the examples on your demo page, the button will remain with darker box shadow and darker button shade.

[mwilc0x]

Actually, looks like it is a result of trying to use <md-button> inside <ion-nav-button>

    <ion-nav-buttons side="left">
        <md-button class="md-raised" ng-click="close()">Close</md-button>
    </ion-nav-buttons>

Is there a recommended way for mashing up these two?

I have a <md-button> inside an <ion-item> and it is working great, the focus is removed correctly.

        <ion-list>
            <div ng-repeat="foo in baz.bar">
                <ion-item class="item-stable">

                    <div class="row">

                        <div class="col-30">
                            <md-button class="md-raised" ng-click="selectFoo($index)">Open</md-button>
                            <md-button class="md-raised" ng-click="copyFoo($index)">Copy</md-button>
                        </div>

                    </div>

                </ion-item>
            </div>

        </ion-list>
``

[marcysutton]

This is a known issue, and it has to do with how buttons natively stay focused after you click them. @robertmesserle @rschmukler I'm remembering we talked about a fix for this briefly last week. #556

[rschmukler]

@marcysutton I think our best bet might be a pure JS implementation of focus that then applies a md-focused class which is auto removed after a timeout. Pressing a key re-applies it to the last known element (or, the next one)...

We could then style off of md-focused and do away with how the browser handles it

[marcysutton]

That sounds smart to me, seeing how much of a pain it is cross-browser.

[marcysutton]

Except if you are using the keyboard, focus should stay until you blur the element, not after a timeout. The challenging part will be discerning mouse clicks from keyboard clicks (button elements trigger click events from the keyboard).

[rschmukler]

Could we use the absence of e.keyCode to identify it as a mouse click?

[marcysutton]

You don't get keyCodes from a click event, only keypress. They always come back as 0. Here's a sandbox I use to test stuff like this: http://codepen.io/marcysutton/pen/YPxrLd