If I set some html content for a contenteditable div then I’m unable to focus into it properly on Android (testing with a Nexus 5). If you try really hard you can occasionally get the caret to show but it’s basically not working.
Following codepen demonstrates the issue: http://codepen.io/emertechie/pen/mApya
Focus is working fine if I just set plain text with .text() and everything works ok on iOS.
I tried setting overflow-scroll="true" on the content area to disable the Ionic scroll in case that was the issue, but same problem. I also tested with a vanilla Cordova project and the issue doesn’t occur. So I think it’s something to do with Ionic library.
I’m a bit stumped. Really appreciate any suggestions.
Can you try this
*[contenteditable] {
-webkit-user-select: auto !important;
}
Thanks for suggestion but that didn’t help.
It there’s anything else I can try, let me know. Otherwise should I consider this a bug and log an issue?
(Btw when I inspect the webview via Chrome it shows the calculated property as ‘text’, not ‘auto’ but I’m sure that’s nothing)
Try replacing it with text instead of auto. I don’t have an android phone on me right now so I can’t do any testing of mine own.
Yea I tried text already and same issue.
I’ve been comparing the css from vanilla cordova project (where focus works) with Ionic one and I can’t spot anything obviously different that would cause an issue.
Hmm, alright. When I get to my office in the morning I will test this on my android phone and try to find the issue
Great, thanks. I’m having a bit of a poke around in the Ionic sources. If I find anything I’ll let you know.
Ok so I can hack the source to make focus ‘work’ but I’m not sure of underlying cause.
In tap.js, in tapMouseDown(e) function, e.target will refer to a child element under the contenteditable parent (for example, a <p>) so the value of the .contentEditable property is therefore inherit and not true so this fails the comparison in ionic.tap.isTextInput:
ele.contentEditable === 'true'
If I briefly change that to test for inherit also (obviously not a solution), then the focus works on Android.
Setting a few breakpoints in Android vs iOS, it seems that maybe the order of calls to functions like tapMouseDown, tapFocusIn and keyboardBrowserFocusIn is different between the platforms?
Anyway I’m just fumbling around in the dark really. I’m not sure how it all works! I’ll leave it to you to have a look. Thanks
Update: I noticed that in another place in same file, the isContentEditable property is used. This returns true for the child element so that could be the solution.
@mhartington Did you get a chance to look at this? If you see my update, I think the solution could be to just use the isContentEditable property
Let me know if you want me to open an issue for this. Afraid of it getting lost here
Thanks
Hey looking at it right now. Any particular version that you had trouble with? Just tried 4.4 and it all works fine for me.
Edit:
4.1, .4.2, 4.3 working fine as well with out any modifications
Update, soo I reread the post…totally missed the part where you said that the content of the content-editable div were <p>, <em>, <h2>,etc.
Soo with that being said…I’ll look into tap.js a bit more, but any particular reason why you’re using content-editable?
Yea I was testing with 4.4.4 on a Nexus 5. I definitely have issues focusing into top element from codepen earlier. And exact same issues in app (have to use a custom Ionic build to make it usable)
What devices are you using? Are you using nightlies or the beta 11 also?
(btw probably won’t be able to reply until the morning - on Asia time here)
Just saw your last post. Any reason I shouldn’t be using it? 
I’m writing a journalling app and I want it to support basic rich text editing like bold and italics. And apart from that, contenteditables are a much better fit because I want to lay things out in an ‘outliner’ (bullet-point list) style.
I do seem to be bumping into a few issues related to contenteditables so I guess it hasn’t got much use before. If you’re in the mood, couple of other issues I logged related to them:
https://github.com/driftyco/ionic/issues/1897 (PR pending)
https://github.com/driftyco/ionic/issues/2091
thanks
So talked with the dev about content-editable divs,
Soo right now there not really something we would suggest.
They can be problematic and we haven’t really tested them with ionic.
Instead we suggest using textarea’s instead. Since there are issues open with examples/codepens, we will get to it. Just takes some time.
But if you need a rich text-editor, you could try text-angular
“http://codepen.io/mhartington/pen/JCaqr”
Hmm, ok. Have put a good bit of effort into the contenteditable approach and fixing bugs along the way, so not the answer I was hoping for
A full blown editor is overkill for what I need, which is something similar to Workflowy (video).
But ok, realise that contenteditables may not be top priority. Hope you can get to those issues eventually though. For now I guess I’ll have to try textareas.