Move focus to trigger instead of simply blur()ing

[patrickhlauke]

blur() results in a loss/reset of keyboard focus, meaning keyboard users usually get thrown right back to the start of the page. Instead, this moves focus back to the trigger (which had the focus when the trigger was activated).
As with the proposed fix in #418 this obviously results in the focus styles (like the default outline, unless suppressed) being applied to the trigger (see the related PR for rationale and future fix using :focus-ring)

[patrickhlauke]

Looking at the travis failure above...I almost suspect it's a problem with the test rather than with the code change? Or, to put another way: is the function in real world ever meant to execute without a trigger being present (e.g. triggered programmatically)? If so, I guess the code needs to change subtly just to test for the presence of this.trigger in the if()?

[zenorocha]

Hey @patrickhlauke, thanks a lot for sending this pull request.

When testing on iOS, I noticed that focus is not changing even on the user taps somewhere else. See this video comparing before and after this patch: http://cl.ly/kfSv

#418 seems to fix the problem you mentioned and don't throw users back to the start of the page: http://cl.ly/kgAH

Because of that, I'll close this PR for now, but feel free to open another one if needed. Thanks again!

[patrickhlauke]

The problem still appears on the "Copy to clipboard" example (even after #418). I'll have another play now that #418 has landed to see what's what and to address any iOS issue

[patrickhlauke]

looking at the first video, that's a standard iOS behavior: focus, or rather :focus, isn't moved when just tapping arbitrarily on the page. once something has focus, only tapping on something else that receives focus removes the focus. I know blur() is a common cheap way of suppressing this, but it does cause focus to reset (noticeable particularly on that "Copy to clipboard" example)

[patrickhlauke]

see https://youtu.be/Ekq81Z1tqUo that illustrates the problem still being present. for iOS, there's no nice way to suppress the quirky iOS behavior (it's consistent with how iOS behaves... blur - the JS event - is similarly not fired unless tapping away to another focusable element, see https://patrickhlauke.github.io/touch/tests/results/#mobile-tablet-touchscreen-events).

there's no clean way to suppress this iOS behavior AND to keep sane keyboard focus, as far as i'm aware. i'd personally say having the focus (and tooltip) remain visible in iOS is a small price to pay in order for these controls to not completely mess up keyboard users. unless you implement some other more neutral additional "target" (like an extra neutral element, like a <span tabindex="-1"></span> that you can then programmatically focus() (rather than blur()ing and sending focus hurtling back to start of the document)

[gauntface]

Would any of this be an issue if the executeCommand didn't require the selection of text to work?

The fact you are having to mess with focus state to copy something to clipboard feels pretty wonky.

[zenorocha]

No @gauntface, this only happens because we need to perform a selection for execCommand to work.

@patrickhlauke I think we'll need to update the site as well to prevent this from happening:

[patrickhlauke]

I think we'll need to update the site as well to prevent this from happening

"this" being the tooltip not clearing after focus is moved away from the buttons (and the tooltip showing again once the same button receives focus again)? without looking at the code, i'd guess that adding a blur listener that clears the tooltip should do the trick

[patrickhlauke]

just force-pushed a tiny tweak (change to the preceding if() statement) which should hopefully keep travis happier...

[patrickhlauke]

regarding the sticky tooltips - #420

[zenorocha]

Thanks @patrickhlauke! All merged and published!

[patrickhlauke]

Good stuff :)

I'll double-check tomorrow that everything's working as expected, but thanks for being amenable to the change in iOS behavior! (there are ways to work around it, but they're ugly and involve hacking specifically around iOS' quirks with additional JS and empty noop handlers to force event bubbling - see twbs/bootstrap#22426)

[zenorocha]

Interesting, thanks for sharing! I appreciate you taking some precious time to work on this ;)