Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
527 views
in Technique[技术] by (71.8m points)

javascript - Why Is My Contenteditable caret Jumping to the End in Chrome?

Scenario

I have a contenteditable <div> area, and within this area I may have some <span contenteditable="false"></span> containing some text. The idea is, these span elements will represent styled text that can not be edited, but may be deleted from the <div contenteditable="true"></div> area by pressing the backspace key.

Issue

The cursor placement is the big issue here. if you delete one of these <span> elements, the cursor jumps to the end of the <div>. More interesting, if you type some text while the cursor is "at the end," the text placement is just fine... Then, if you delete the newly typed text, the cursor jumps back!

I have prepared a fiddle which will demonstrate this. I need this to work only in Chrome, and other browsers are either of non-concern for now or have workarounds in place. (Also note the prepared Fiddle is crafted to demonstrate this in Chrome only).

Fiddle


Fiddle Instruction: Chrome Version 39.0.2171.95 m (64-bit) reproduced in 32-bit as well

  1. Click into <div> area
  2. Type "123"
  3. Backspace "3" Backspace "2" Backspace "1" enter image description here

Related Details

Researching this extensively, I have come across various SO question that are similar, but borrowing the associated solutions has not proved to be the silver bullet I am after. I have also found issues for the Chrome project which seem to target (perhaps not in the exact manner) the issue described above, and can be viewed below.

  1. Issue 384357: Caret position inside contenteditable region with uneditable nodes
  2. Issue 385003: Insert caret style is wrong when reaching the end of a line in a contenteditable element
  3. Issue 71598: Caret in wrong position after non-editable element at the end of contentEditable

The closest SO solution I have found can be here. The idea in this solution is to place &zwnj; characters after the <span> elements, but if I want to now delete my <span>, I instead delete the &zwnj;... forcing my cursor to jump to the end, offering a weird UI experience by not deleting my <span> on my "initial delete key stroke."

Question

Has anyone experienced this issue and found a work around? I welcome any possible solution, even as JS hacky as they come. I've come to learn that leveraging contenteditable comes with a laundry list of struggle, but this seems to be the last remaining difficulty I currently have.

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

I don't know why this happens, but I had the feeling it has something to do with the sizing of the <div>, so I tried playing with the display property. After setting it to inline-block and playing a little with the text I found that the issue is gone after I make some edits to it, specifically adding a new line.

I saw that, for some reason, the <br/> tag is kept in div.main after I delete my new line, but the appearance of the <div> and the way it responds to arrow keys is the same as if there is no new line in it.

So I restarted the fiddle with the CSS change and a <br/> tag in div.main and viola!

So to conclude:

  1. Add display: inline-block to div.main
  2. add a <br/> at the end of div.main

JSFiddle Link


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...