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.

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

Jangro

Seems to be an older problem: #1987935 – Bemused

I'm still noticing it as well. – Fashion

@Fashion - 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) – Jangro

Unbelievably, this problem still persists in 2018. – Theaterintheround

Answer 1

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"
    }   
}

Bemused

no I cannot, It MUST be absolute. must. (this is a simplified version of my problem after all). this is a crazy FF bug.. – Jangro

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. – Bemused

it should be faded out. not gone. gone is the thing I want to avoid here. only faded out.. – Jangro

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: 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 – Bemused

I've updated my answer with a solution that should suit your usecase – Bemused

hmm your fiddle doesn't do anything to correct the issue..are you sure you put the right link? – Jangro

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. – Bemused

yeah, sadly it seems like better to avoid such things until the future will come and such awfulness will be behind us. – Jangro

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. – Aludel

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. – Jangro

Answer 2

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

Fashion

Answer 3

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;
}

Outboard