Experimental support for EditContext

Chrome has started shipping edit context, a feature that allows JavaScript to intercept editing actions, including composition-based ones, in a way that isn’t as problematic as the old ‘just see how the DOM changes and hope for the best’ approach. Mozilla is considering the proposal but hasn’t put out a position yet. Apple is responding with deafening silence as usual.

I’m generally a bit wary of Blink-only APIs, but since this may help tame the endless mess of virtual keyboard behavior on Andoid, I built a proof-of-concept implementation that uses this feature, when available, to capture text input. The interface was surprisingly pleasant to use, and fits into CodeMirror rather well. My implementation is in this branch, and available as @codemirror/view 6.26.4-edit-context on npm (under a separate tag).

I would appreciate help testing this. I’m sure there will be new bugs, both in my integration and in Chrome itself (I already ran into a rather bad one in Chrome), but those can hopefully be found and worked out in the near future. Once I’m more confident this is solid, I’ll move it to the main branch, possibly, depending on how solid, behind an option.

5 Likes

This is very exciting!

Would you be open to providing an option for this now, rather than later? It’s fine if it is still in its own special branch. We want to test this at Replit but we’d like to be able to restrict it to just our opt-in beta testers. It would also let us do a semi-graceful fallback if we detect errors.

I’ve published a 6.26.4-edit-context.1 that allows you do EditorView.EDIT_CONTEXT = false to disable use of edit context. This will not be a stable feature, just a kludge that exists as long as this is experimental.

Were you able to do any testing on this? Any feedback so far?