New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IME not working on mobile #3137

Open
jackycute opened this Issue Mar 16, 2015 · 17 comments

Comments

Projects
None yet
@jackycute
Contributor

jackycute commented Mar 16, 2015

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

This comment has been minimized.

Member

marijnh commented Mar 18, 2015

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

This comment has been minimized.

Contributor

jackycute commented Mar 18, 2015

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!

@marijnh marijnh added IME mobile labels Sep 2, 2015

@lackneets

This comment has been minimized.

lackneets commented Dec 21, 2015

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

@jackycute

This comment has been minimized.

Contributor

jackycute commented Dec 28, 2015

Tks! @lackneets

@episodeyang

This comment has been minimized.

episodeyang commented Dec 4, 2016

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

This comment has been minimized.

Member

marijnh commented Dec 15, 2016

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).

@episodeyang

This comment has been minimized.

episodeyang commented Dec 15, 2016

Hey @marijnh! How is it going : )

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

@zxl777

This comment has been minimized.

zxl777 commented Dec 26, 2016

+1 I am waiting for these updates too ;)

@EveLuty

This comment has been minimized.

EveLuty commented Apr 26, 2017

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

@barretlee

This comment has been minimized.

barretlee commented Jun 2, 2017

How is it going? seems still not working.

@barretlee

This comment has been minimized.

barretlee commented Jun 2, 2017

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

This comment has been minimized.

Contributor

adrianheine commented Jun 2, 2017

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

This comment has been minimized.

gfx commented Jul 27, 2017

The same in iOS Safari with Japanese IME.

@gfx

This comment has been minimized.

gfx commented Jul 27, 2017

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

This comment has been minimized.

inductor commented Apr 20, 2018

What's up with this issue? :s

zakahiro added a commit to zakahiro/CodeMirror that referenced this issue May 12, 2018

@mhlx

This comment has been minimized.

mhlx commented Jun 11, 2018

thank you @zakahiro

@adrianheine

This comment has been minimized.

Contributor

adrianheine commented Sep 6, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment