codemirror / codemirror5

In-browser code editor (version 5, legacy)
http://codemirror.net/5/
MIT License
26.76k stars 4.96k forks source link

IME not working on mobile #3137

Open jackycute opened 9 years ago

jackycute commented 9 years ago

I upgraded to version 5.0 several days ago. But I found that I cannot type chinese on the mobile. It will show the raw Bopomofo like this "ㄋ一". Which should only stay in IME or composition event.

BTW, if I force to use "textarea" mode in inputStyle config. It can type chinese correctly but not the auto complete from built-in keyboard. If you do so, It will lost focus and we need to click other lines again to type, or nothing will show up. And this bug is persist from version 4.9, confirmed by me.

Thanks for any support, CodeMirror is awesome!

marijnh commented 9 years ago

That's interesting. Do you see the same problem on desktop CodeMirror when you explicitly enable the "contenteditable" input style?

One possibility is that input.forceCompositionEnd is being called when it shouldn't. Could you try to verify that with a console.log? Another possibility is that the IME software is getting confused by some aspect of CodeMirror's DOM behavior, and is itself prematurely ending the composition because of that.

I unfortunately know very little about both Chinese writing and Chinese IME. For me to debug this you'd have to walk me through the procedure of enabling it on the mobile platform you are using, and explain what you are doing and what the expected outcome is. (If the problem also manifests itself on the desktop, that would help. I have a Japanese IME installed, but a quick test didn't show any problem using that with contenteditable mode.)

jackycute commented 9 years ago

No, desktop version using "contenteditable" input type won't cause this, but using this mode in Chrome is extremely slow, I don't know why. Both Input types in desktop version are fine, very cool.

The good new is, I found I can debug on mobile via Safari, which my iPhone connected to my Mac.

Let's talk about "textarea" mode in mobile first. The real problem is, when I input in composition, the backspace action didn't trigger any composition event, and instead, CodeMirror found I click the backspace and clear its textarea, which cause the built-in autocomplete failed and lost focus to where I didn't know. Then I need to click finish on my keyboard and click to another line to type again. btw, there is a built-in blinking cursor in iOS Safari, which sometimes not at same position as CodeMirror's cursor.

Then, I checked the "contenteditable" input type on my iPhone, it was quite interesting. When I type in composition like Bopomofo, as I previous mentioned, it just show them but not combine to the Chinese word I want. But if I click the built-in keyboard for auto complete, it can input the auto complete Chinese word! And the console bump for three event: compositionstart, compositionupdate, compositionend in a time. So, I go find is there a event firing specifically on auto complete, then I found input event on contenteditable. It will fire twice input when I click on the auto complete word. In the end, I inspect the keydown event, it only receive event which keyCode is 0 when I type Bopomofo. Same as Japanese input on iPhone safari.

input.forceCompositionEnd is not called ANY at both input types and both languages.(Or maybe I inspect it in a wrong way)

In Bopomofo(it's Tradition Chinese), if you type ㄋ一, it should show several items included the on the built-in keyboard's auto complete list, and you choose which you want to input the word, much like Japanese.

Hope these tests will help you, it's so confusing why mobile browser behave so strange. But in the example of the html5doctor, I am completely fine to type Chinese and Japanese there. http://html5doctor.com/the-contenteditable-attribute/ Thank you again!

lackneets commented 8 years ago

I have the same problem. Here I found a hack solution: not pretty well but works https://github.com/zhusee2/codemirror-composition-mod

jackycute commented 8 years ago

Tks! @lackneets

geyang commented 7 years ago

Hey guys:)

Has there been any update on this? If Jacky's solution is good, maybe we can incorporate it into the core code base?

marijnh commented 7 years ago

I suspect the issue is that Safari/Mobile Safari are very easily confused when a JavaScript program messed with the editable DOM, and will either get confused (as in the auto-capitalizing of the keyboard) or fail to treat the updated content correctly (similar problems exist for spell check and double-space-for-period). In ProseMirror (a rich text editor) I've managed to work around this by letting the native behavior through and only updating the DOM when absolutely necessary. Eventually, I want to move CodeMirror's contenteditable mode to this approach as well, and I suspect it will help for this issue, but that's going to be a bunch of work it might take a while before I get to it.

As for the mod at https://github.com/zhusee2/codemirror-composition-mod , that looks like it'll cause more problems than it solves (it resets the DOM during composition, which will often force the composition to end, and it blindly trusts the data in the composition events, which is inaccurate on many platforms).

geyang commented 7 years ago

Hey @Marijnh! How is it going : )

Yeah, that sound reasonable. I will wait for these updates:)

zxl777 commented 7 years ago

+1 I am waiting for these updates too ;)

EveLuty commented 7 years ago

is there anything new for that ? I found that problem also in my project.. if there are some update, it will be great. :+1:

barretlee commented 7 years ago

How is it going? seems still not working.

barretlee commented 7 years ago

textarea input style has lots of other problem, such as cannot select words.

I have an idea, we do not hidden textarea, rather put it under the rendered div, set opacity to 0, it may resolve the selection problem .

adrianheine commented 7 years ago

Eventually, I want to move CodeMirror's contenteditable mode to this approach as well, and I suspect it will help for this issue, but that's going to be a bunch of work it might take a while before I get to it.

Just for clarity, this is something @marijnh would like to see happening, but currently neither has time nor funding to do so afaik.

gfx commented 7 years ago

The same in iOS Safari with Japanese IME.

gfx commented 7 years ago

With inputStyle: "textarea", IME works well, but the native cursor for textarea also displays in addition to the CodeMirror cursor.

https://gyazo.com/27609595431a20b15f4f6540afe12602

The black one is CodeMirror's cursor while the blue one is the native textarea's.

inductor commented 6 years ago

What's up with this issue? :s

wwwqyhme commented 6 years ago

thank you @zakahiro

adrianheine commented 6 years ago

This is a issue that's difficult if not impossible to solve with the fundamental approach currently taken by CodeMirror.

We are working on a rewrite (CodeMirror 6) that will address this issue, and we are currently raising money for this work: See the announcement for more information about the rewrite and a demo.

Note that CodeMirror 6 is by no means stable or usable in production, yet. It's highly unlikely that we pick up this issue for CodeMirror 5, though.

wwwqyhme commented 4 years ago

After I upgrade my iphone to 13 , the default input method worked correctly , the third party input method still has problems