Firefox sets wrong caret position contentEditable with :before

Question

playground

This is a simplified version of my problem.
seems like I cannot put a positioned pseudo element inside a contentEditable and yet have the caret positioned in the correct place when clicking to get focus on the contentEditable element.

enter image description here

div{ padding:10px; border:1px solid #CCC; height:120px; position:relative; }

div::before{ 
  position:absolute; 
  top:10px; 
  left:10px; 
  content:"placeholder"; 
  color:#AAA; 
  transition:.2s;
  opacity:0;
}

div:empty::before{
  opacity:1;
}

<div contentEditable></div>

UPDATE - FOUND THE REPORTED BUG:

please vote for this bug to be repaired - https://bugzilla.mozilla.org/show_bug.cgi?id=904846

Seems to be an older problem: http://stackoverflow.com/questions/1987435/contenteditable-cursor-position-style-in-firefox — Nico O, Feb 24 '14 at 12:03
@Dex - that's because they haven't fixed it...you should "star" if you care about this. There is a link to the reported bug in my question (bottom) — vsync, Jan 15 '15 at 14:22

score 6 · Answer 1 · edited May 29 '16 at 13:30

6

There is a problem when you put the :after element to absolute. I can not figure out why. But if you just place it relative the problem is gone.

I've updated your fiddle: http://jsfiddle.net/NicoO/Lt3Wb/1/

Here is the new CSS (with some experimental additions)

$pad:10px;

div{ 
    padding:$pad; 
    border:1px solid #CCC;
    height:120px;
    position:relative; 

 &:before
 { 
     position:relative;
     color:#999;
     content:"Write a comment..."; 
 }   
}

div:focus
{
    border-color: red;
}

div:not(:empty):before{
    display: none;
}

The only problem that remains is, that you can focus behind the text of the :before element. That'll be why you wanted it absolute. Interessting also: If you put the pseudo element to float: left; it shows the same behaviour as on position:absolute;.

Update

When you are forced to use absolute on peseudo elements, there seems to be only one solution at the moment. Define another padding for the box as long as it is empty and focused. Playground: http://jsfiddle.net/NicoO/Lt3Wb/5/

$pad:10px;
#test
{ 
    padding: $pad; 
    border:1px solid #CCC;
    height:120px;
    position:relative; 
    overflow: hidden;
    -moz-box-sizing: border-box;
    -webkit-box-sizing: border-box;
    box-sizing: border-box;    

    &:empty:focus
    {
        padding: #{($pad*2)+6} $pad; 
    }

    &:before 
    { 
        position:absolute;
        color:#999;
        top: $pad;
        left: $pad;
        content: "Leave a comment"
    }   
}

edited May 29 '16 at 13:30

Eugene

4,352
8
55
79

answered Feb 24 '14 at 12:14

Nico O

13,762
9
54
69

no I cannot, It MUST be absolute. must. (this is a simplified version of my problem after all). this is a crazy FF bug.. – vsync Feb 24 '14 at 13:36
Ok, i'll try it with that parameters. One question: When do you want to remove the :before element? If it can be gone on focus there will be no problem after all. – Nico O Feb 24 '14 at 13:42
it should be faded out. not gone. gone is the thing I want to avoid here. only faded out.. – vsync Feb 24 '14 at 13:45
It's strange for sure. I think the contentEditable attribute is persiting on the child pseudo element and is "confusing" the browser. Have a look at this: http://jsfiddle.net/NicoO/Lt3Wb/2/ would this be a solution? > Sometimes the Cursor came above the inline item. But i could not reproduce this the last 100 clicks. You dont need to apply `contenteditable="false" ` on the inline-label – Nico O Feb 24 '14 at 14:04
I've updated my answer with a solution that should suit your usecase – Nico O Feb 24 '14 at 14:20
hmm your fiddle doesn't do anything to correct the issue..are you sure you put the right link? – vsync Feb 24 '14 at 14:52
I'am sorry. I did not test this version with Chrome. Currently the only solution i see is to wrap the `:empty:focus {...}` declation inside of `@-moz-document url-prefix("") { HERE }` But that fails with Scss. maybe you are more advanced escaping this. – Nico O Feb 24 '14 at 15:53
1

yeah, sadly it seems like better to avoid such things until the future will come and such awfulness will be behind us. – vsync Feb 24 '14 at 16:40
1

It's incredible that these browsers can't agree on a single architecture standard. It's almost impossible to release a web site anymore without having to work around all the browser bugs/quirks. I really hope this gets fixed soon. – Aedaeum Jun 01 '14 at 10:52
4

If I was the dictator of the world I would first eliminate all browsers except one, and focus all engineers of all the other browsers to join and fix all the bugs of the browser-of-choise in a single week to make it perfect. Humanity deserves this. – vsync Feb 12 '15 at 09:13

Dex · Answer 2 · 2015-01-15T04:29:31.710

For me this was only a problem when the box was empty. So I seeded it with a <br>:

  $("[contenteditable='true']").on('focus', function(){
    var $this = $(this);
    $this.html( $this.html() + '<br>' );  // firefox hack
  });

  $("[contenteditable='true']").on('blur', function(){
    var $this = $(this);
    $this.text( $this.text().replace('<.*?>', '') );
  });

More info here: https://bugzilla.mozilla.org/show_bug.cgi?id=550434

score 0 · Answer 3 · answered Oct 23 '14 at 11:04

One work around of this problem is to wrap the content-editable inside a DIV and give to this DIv a fixed height.

That is, if you have a configuration like this :

<div id="wrapper">
    <div contentEditable></div>
</div>

Then the CSS can be the following :

#wrapper {
  width: 240px;
  height: 70px;
  margin: 0 20px 0;
  overflow-y: auto;
  overflow-x: hidden;
}

#wrapper div[contenteditable=true] {
  width: 100%;
  min-height: 35px; /* Not mandatory */
  padding: 8px;
}

Firefox sets wrong caret position contentEditable with :before

playground

UPDATE - FOUND THE REPORTED BUG:

3 Answers3

Linked