25

There seems to be a bug in IE10, where if I place an element over another element with the contenteditable attribute, the editor's caret is drawn over everything.

You can see this behaviour below in the image below and in this jsFiddle.

Example

I've mucked around with plenty of CSS properties, and been unable to find a solution to this. It works as expected in other browsers.

The reason I need this is because I am designing a WYSWIYG editor (TinyMCE fork) experience where the toolbars slide down over the text when they're required. This bug makes the caret appear over the top of the toolbar.

The only solution I have thought of is to blur the editor's focus, and refocus it when the toolbar has disappeared. However, this will stop users from typing when the toolbar is activated, and would also cause inconsistent behaviour across browsers.

Is there a workaround to this bug?

alex
  • 479,566
  • 201
  • 878
  • 984
  • if you don't want to edit, you can set focus on some `input` elsewhere on the page. – el Dude Apr 04 '13 at 01:13
  • @EL I was hoping to allow the users to continue to edit. Maybe I can just disable it for IE10. – alex Apr 04 '13 at 02:17
  • @alex For the record, this will happen with a regular `input` as well; the `contenteditable` attribute isn't needed. That being said, I saw this months ago and never found a solution either. – Sampson Apr 08 '13 at 02:21
  • @JonathanSampson Didn't even think to check that. – alex Apr 08 '13 at 02:28
  • 2
    This happens in IE way back (probably back to 5.5), not just IE 10. It's arguable whether it's even a bug. – Tim Down Apr 08 '13 at 16:44
  • Possible duplicate of: http://stackoverflow.com/questions/1823808/hiding-the-text-input-cursor-the-caret-showing-through-overlayed-elements-inte – Cᴏʀʏ Apr 08 '13 at 18:04
  • Neither CKEditor nor TinyMCE have fixed this issue over last 10 years so I'm afraid that there might not be other solution than blurring editable when opening toolbar. – Reinmar Apr 08 '13 at 18:47
  • Another Microsoft 'feature' rather than a bug? – Paul C Apr 09 '13 at 09:19
  • 1
    Lol... this is incredible. I just installed IE10 on Win7, trying to open your fiddle and it crashed. Completely. "Internet Explorer has stopped working". Then I was thinking, I know the [Mercury](http://jejacks0n.github.io/mercury/) editor, which has a history tab lying over the contenteditable field. So I said to myself: "Let's see how they did it!". Answer: They did not. "Sorry, but Mercury Editor isn't supported by your current browser." Seriously: After leaving out 3 IE Versions working on chrome MS couldn't possibly disappoint me more... – Hannes M Apr 12 '13 at 05:58

4 Answers4

6

There is no way to overlap the caret with another element in IE. This question was asked many times:

...

But you can blur the textarea after getting the caret position (see: Caret position in textarea, in characters from the start) and then show your toolbar. After hiding the toolbar, you can focus the textarea again, setting the caret position with:

function setCaretPosition(elemId, caretPos) {
    var elem = document.getElementById(elemId);

    if(elem != null) {
        if(elem.createTextRange) {
            var range = elem.createTextRange();
            range.move('character', caretPos);
            range.select();
        }
        else {
            if(elem.selectionStart) {
                elem.focus();
                elem.setSelectionRange(caretPos, caretPos);
            }
            else
                elem.focus();
        }
    }
}

See: Set keyboard caret position in html textbox

Community
  • 1
  • 1
Stephan
  • 1,246
  • 8
  • 16
  • Surprised I couldn't find the duplicate question, and I spent hours looking. Thanks for your answer. The problem with blurring the focus is that the toolbar has all the options for bold, italics, etc. When I blurred the textarea, the user's selection was missing (at least as how TinyMCE detects it). – alex Apr 08 '13 at 23:41
  • Better to give someone the 500+ rep, even if this doesn't solve the problem for me in particular. – alex Apr 14 '13 at 23:51
  • thanks! I would be very interested to know if you find a way/workaround. – Stephan Apr 15 '13 at 18:47
3

Add -ms-user-select: none to the contenteditable element. Setting focus will then not show the cursor - guessing a browser quirk. Cursor will probably reappear once you hit left/right or type another char though.

user2242847
  • 31
  • 1
2

You can simulate a caret with JavaScript and CSS and customize it.
With proper customization you can build a practical workaround to this bug.

Here is an interesting article on how to do this:
http://www.dynamicdrive.com/forums/showthread.php?17450-Emulating-a-terminal-like-caret-with-javascript-and-css

Here is a demo:
http://shachi.prophp.org/demo.html

Also, there is a jQuery Terminal Emulator plugin that you can fork and customize to your specific needs:
http://terminal.jcubic.pl/#demo

Arbel
  • 30,599
  • 2
  • 28
  • 29
  • I don't believe this will work with a `contenteditable`'d element very well. – alex Apr 09 '13 at 07:45
  • The first doesn't work if you keep pressing `Del` (caret deletes the wrong character and disappears to the left), the second doesn't work with US-International (quote+space prints just space). Anyway this is a workaround, not a solution. – CodeCaster Apr 09 '13 at 07:51
  • It is hacky somehow but could be tested in a small experiment to make sure it works well. Maybe it will be worth doing if it is going to provide flawless experience for your IE users. – Arbel Apr 09 '13 at 07:51
  • The jQuery plugin doesn't seem to have the `Del` problem. Good catch for `Del` on the other one, so it also needs improvement in its core! – Arbel Apr 09 '13 at 07:53
1

Well the obvious workaround is to decrease the height of the contenteditable div and show the toolbar above the editable area instead of on top of it.

Erik Nijland
  • 1,181
  • 2
  • 9
  • 24