md-toolbar and sidenav focus problems

[devversion]

For testing purposes I tried to create a sidenav, which should be triggered by the toolbar
But as you can see in the bad quality GIF, the css class is-focused will be added after dismissing the sidebar. So I already checked the code and I found this snippet

return $q(function(resolve){
  // Toggle value to force an async `updateIsOpen()` to run
  scope.isOpen = isOpen;

  $mdUtil.nextTick(function() {
    // When the current `updateIsOpen()` animation finishes
    promise.then(function(result) {

      if ( !scope.isOpen ) {
        // reset focus to originating element (if available) upon close
        triggeringElement && triggeringElement.focus();
        triggeringElement = null;
      }

      resolve(result);
    });
  });

});

I already fixed that in my version, but I want to ask the development team first about their thoughts.
So I created a merge for that, please take a look at it and tell me more about potential side-affects

@jelbourn @ThomasBurleson

[devversion]

I referenced my both commits :) please take a look :)

With Fix 2, you simply need to add the flag nofocus to the md-button

This happens too, on the docs

[jelbourn]

cc @marcysutton

I believe that focus is there on purpose for accessibility reasons (indicates to keyboard users where the focus is).

[devversion]

That's why I thought about creating an extra attribute which prevents focus recovery.
What do you think about that?

If you found a good solution, you can tell me :)

[marcysutton]

Rather than providing a way to break accessibility, a proper solution for this would involve something like #5189: only show the focus style on keyboard interaction. Mouse users wouldn't see it. We definitely should not provide hooks to disable accessibility features, but rather apply those features in more specific ways.

[devversion]

https://github.com/ten1seven/what-input

That isn't a good solution for detecting the interaction type, because then I need to bind a listener on the triggeringElement. The Problem with binding the listener to the element is: I only get the current triggeringElement after the event is already triggered, so this would be useless.

Should I instead check for the global input methods? (like: touch or mouse)

[marcysutton]

Did you look at the library? It is checking global input methods. Consumers of the library don't have to do anything except include it and write some CSS. That said, I didn't think we would necessarily use a third-party lib in Angular Material, but I wanted to float it up as an example.

[devversion]

Yeah, I took a look at it ;), so we should provide an own version of that with less features?

[marcysutton]

That's the idea, yes. We don't need the full event API, just input detection allowing us to apply focus styles on keyboard interaction only.