Issue Report (CJK)

What problem?

When entering a CJK character, there is a character that has not been determined after entering it and before finalizing the conversion. (e.g. にほん => Enter => 日本)

If a synchronization occurs between the time you type and the time you confirm the conversion, the characters before and after the conversion will be typed twice. (e.g., にほんにほん)


To prevent this, you must reject synchronization between the time you start input and the time you finalize the conversion. Specifically, it’s between the compositionstart event and the compositionend event.

I looked it up, and it seems that Dropbox paper is preventing this problem in a similar way.


So my question is, is there an API to stop the synchronization (receive and send websocket) temporarily? That would seem to solve the problem.

Greetings. I think we might need to look at this a little closer. A few questions:

  • Can you detect when this is happening?
  • Which text editing components are you using?
  • Are you using one of our adapters?

We might be able to figure out a work around if we can replicate the issue.

There is the concept of a batch operation. The batch operation prevents sending individual operations to the server and ensures that a grouping of operations go to the server in a batch, but I am not sure this would help.

I assume you are referring to this event? If so, the underlying adapter probably just needs to be updated to trigger the Convergence RealTimeString.insert event from the browser compositionend rather than e.g. keyup. So, I suspect you could handle this at the adapter level. For example, you could try forking and modifying our collaborative textarea here.


Can you detect when this is happening?
Which text editing components are you using?
Are you using one of our adapters?

This problem occurs in all demos of convergence. More to the point, it also happens in other libraries, such as firepad.

This will happen if you enter a full-width character and it is synchronized while selecting the conversion. It’s hard to understand if it’s just words, so I made a GIF.


This is an example reproduced in textarea. I’m only typing “あああ”, but when the sync occurs in the middle and then is confirmed, it’s typed as “ああああああ”.(あああ * 2)
(“your area”'s counterpart typed “a” before I typed “あああ” in “my area” and confirmed the conversion.)

Thank you.
Yes. I’ll try to adjust in my personal environment.Let’s take a look at the hints given (RealTimeString.insert, TextInputManager class). Thank you very much.

Thanks. To be honest I don’t think we have much experience with these types of characters. That said, we’d be happy to work with you to update our text adapters to enable this by default. How an we help?

Thank you very much for your polite response.

If you don’t have an environment that can reproduce the problem (input full-width characters), I think it’s hard to improve.

It’s just a matter of changing the client side, so I’ll try to improve it when I have time in the future. I will report back to you then.

Since the art of collaborative editing is not widespread (e.g., using ShareDB from scratch is difficult for individuals), I am sincerely grateful to have a project like Convergance.

I hope it develops.