I’m just wondering if this is known or not and if there’s anything that can theoretically be done to remedy this?
I had thought this worked when I did some brief testing several weeks back. I’m not sure if my testing was too cursory or if GBoard’s behavior changed. I know some of its behaviors have changed recently, and I’m not sure if this might have affected undo operations.
Is it expected that the gBoard undo would cause varying degrees of mangling of the document? I was under the impression these undo events adhered to some standard. I’m away at the moment so I can’t check the input event types, but it definitely isn’t handled gracefully in the majority of cases I’ve used it in our editor.
I guess these are impossible to identify because Google was so nice as to ignore the spec’s historyUndo and historyRedo and implement it instead using deleteContentBackward and insertText
Fantastic choices.
@marijn I wonder if you have any ideas what might be comparable to determine gBoard undo/redo ? I don’t know that it could be prevented and funneled into ProseMirror’s undo/redo system but those concerns are moot if the events can’t even be identified.
I know ProseMirror view contains some properties like domObserver, input, and trackWrites. I suspect one of these might have some data we could infer from, but without understanding the whole system thoroughly I wonder if I might be overlooking a viable approach?
In the meantime I’d encourage anyone facing this issue to reach out to the Gboard team and ask them to follow the spec and emit historyUndo and historyRedo instead of or addition to their existing events.