You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This currently binds keypress events to document.body, so it's not unlikely this could conflict with other applications' keybindings.
We should fix this so that glift can be happily embedded with more involved applications. It does have a potential of causing problems for users if they don't give focus to glift.
On way to solve that design problem would be to have a keyboard icon that is solid when glift has focus, and greyed-out when it doesn't ?
Don't write any code yet, I may have a PR for you.
The text was updated successfully, but these errors were encountered:
So to summarize from the PR, the method is to use tabindex=0 and focusfor an individual div. If I click away from the box, the div becomes unfocused and key events stop working. This is probably fine although slightly different than the current behavior, but I worry about integration in other pages. I noticed when I tried this out on www.gliftgo.com that the div gets an annoying border around it, although it looks like this can be solved with outline: none;
The other solution is to use contenteditable, but that's obviously not ideal.
Re: https://github.com/Kashomon/glift/blob/0625a4e33d6e5472691a980b05641151589adc48/src/widgets/options/base_options.js#L461-L466
We should fix this so that glift can be happily embedded with more involved applications. It does have a potential of causing problems for users if they don't give focus to glift.
On way to solve that design problem would be to have a keyboard icon that is solid when glift has focus, and greyed-out when it doesn't ?
Don't write any code yet, I may have a PR for you.
The text was updated successfully, but these errors were encountered: