This issue happens only on Macs with Chrome and Safari.

It is related to the IME (input method editor) that is used to enter Japanese (Hiragana) words with Latin keyboards. Such an IME is provided by Windows and the Mac operating system. Part of the process to enter Japanese text is to enter several characters, then press the space bar to get a popup list of suggestions for potential words. The space bar is then pressed again until the desired word is highlighted. Then the user will press return to select the correct word. The user then presses the next characters to build the next word.

If you need more information about typing Japanese text you can find a description here: https://www.coscom.co.jp/learnjapanese801/howjpdo.html

The bug with RadEditor can be demonstrated with the current RadEditor demo page. (http://demos.telerik.com/aspnet-ajax/editor/examples/overview/defaultcs.aspx) 

To recreate the problem you can go to your RadEditor demo page with Chrome or Safari on a Mac. You will need to enable the Japanese IME in your operating system. This is very easy to do and you can just do a Google search for instructions if you need to.

Then delete all example text. 

Now press the following keys on an English keyboard:

s a t e l o    

(each 2 key combination creates a Japanese character)

You will now see 3 Japanese characters. Now press the space bar. This will open the word selection list. Now press the space bar again, which should select the next words from the list. But instead of selecting the next word, the popup list is immediately closed and some different character are inserted in the content. If you then press another key the content gets completely destroyed and replaced with the key that was pressed. It does not work as expected and it is unusable that way.

If you try the same key sequence with Firefox on a Mac or any browser on a PC you will see how it is supposed to work.

The same problem happens if you would use the cursor down key (instead of the space bar) to select the next item in the list.

The affected browsers work as expected in regular input / textarea fields. It seems to happen only with Telerik's RadEditor control. To narrow down the cause even further I created a JSFiddle demo with a simple control that has the attribute contenteditable=true set. I believe that RadEditor is based on such a control and I wanted to see if the affected browsers may have problems with this HTML feature itself. You can try the JSFiddle demo here: https://jsfiddle.net/q5Lsnjmg/3/     The result is that the affected bowsers work as expected in this demo. This seems to indicate that the Telerik editor control must do something different to trigger this problem.

I also created a video that demonstrates the issue. You can see the video here: https://youtu.be/ANLbXpm5Zko