Focus trap in LiveEditor

[joshwcomeau]

Hi folks!

I noticed that because the "tab" key is used for indentation, it becomes a focus trap for users navigating with the keyboard.

It looks like this was addressed and fixed a couple years back, so I'm guessing this was a regression (maybe it wasn't ported in 2.0?)

I tried implementing this in user-land, but the problem is that adding an onChange function to LiveEditor breaks it, since updates are no longer tracked and rendered in the LivePreview.

Happy to help if there's a consensus on how it should be implemented!

Thanks for this awesome project ♥

[redfieldstefan]

Hi @joshwcomeau, Im taking a look at this and after following some breadcrumbs from this PR #23 it seems escaping the focus trap is handled in the v2 migration to react-simple-code-editor where both the escape or Ctrl+Shift+M (Mac) exits the focus and allows a user to tab through.

From playing around a more custom workaround can be passed down through the onKeyDown prop with an event.preventDefault

<LiveEditor onKeyDown={(e) => {
            if (e.keyCode === 9) {
              e.preventDefault()
              e.target.blur()
            }
        }}
/>

Hopefully I am understanding the issue correctly, I'll see about surfacing this in the documentation

[joshwcomeau]

Hi @redfieldstefan,

Ah, sorry for the delay on this!

I tried your solution and it does work, although it's not quite ideal; the blur causes the body to be focused, instead of the next item in the tabindex. I searched and unfortunately there's no easy solution for this.

Appreciate you digging! Escape and Ctrl+Shift+M is good to know. I suspect that some users won't think to try that. In my own app, I used the suggestion you provided to create a checkbox, so users can enable/disable tab functionality:

I think my ideal solution would be a way to disable tab through a prop, since yeah the blur option I'm using now can be a little confusing for keyboard navigators. Sounds like I'd need to open an issue for react-simple-code-editor though?

Thanks!

[selbekk]

This seems to have resurfaced with use-editable. Is there a viable way to add support for "focus the next element" on escape, for instance?

[selbekk]

The way I worked around this was adding an event handler on the containing element, which listens for the keyup event and focuses the next (or previous) element if you click escape or shift-escape.

This isn't really the best approach, as I'd love to use this to turn on and off the tab-to-indent feature instead. Perhaps a pull request to make the useEditable indentation option configurable through props would be a good idea?