ember-native-dom-helpers
ember-native-dom-helpers copied to clipboard
cibernox
Clicking on TAB and SHIFT+TAB should also fire a blur event
When firing a keyboard TAB event (eg. press TAB button). Browsers behavior is, to throw a keyboard event and also, blur the current document.activeElement.
Currently, we are not doing that in ember-native-dom-helpers. It caused a bit of confusion to understand what's going on, so I think it might be worth to add it as a default behavior.
Thoughts?
This is tricky actually. If we want to replicate the browsers behaviour when using TAB, we should do it properly, which is not simple. I don't oppose tho, I just want to highlight what it would be required.
We'd need to have a special case for tab (and SHIFT + TAB) that gets the first focusable item after what what it's currently focused, or the first one if nothing is focused. This by itself has some tricky rules: all inputs, elements with contenteditable, buttons and links unless they have a negative tabindex. Also, if something has a positive tabindex, we need to obey it. Disabled inputs and elements don't count.
Also, this requires the concept of "what it's currently focused", so I think this feature would require the browser window to be focused for real.
I'm ok with the idea, but it is a hard one.
@cibernox yes, this was the thing that I was concerned about... making it right, is actually mimicking the whole browser tabbing behavior, which is definitely complex. If I am not mistaken, is we will use normal Event instead of KeyboardEvent, things should work. So the question is, maybe we can fake it until we make it somehow? :)
we will use normal Event instead of KeyboardEvent
Can you explain this? I think that a KeyboardEvent is closer to "reality"
@cibernox yes it does. I tried to say that - looks like, using just a simple Event solves the issues, and tabbing works, while using keyboard event it doesn't. So maybe there is a way, how we can have a 'fallback' to the simple Event. But I am not exactly sure how we can implement it, without breaking stuff a lot :)
Wait, you mean if that if you fire a generic Event instead of a KeyboardEvent the browser blurs the active element? Really? That makes no sense to me.
@cibernox before I'll say that, I'll verify it again :) I might've mistaken this behaviour yesterday with something else :)