Not sure how to edit the issue at this point.

Chrome version: Version 63.0.3239.132 (Official Build) (64-bit)
OS: Mac.

Mac:10.12.6 (16G29)

When omitting background-color, it works as expected.
Not sure how background-color affects.
Caret positions in DOM are same for both with and without background-color

Note: range selection is painted: https://jsfiddle.net/sn4hkLzr/4/

xiaochengh@, could you check a result of LocalCaretRect()?

# Layout Tree with position:relative and background-color
layer at (0,0) size 800x600
  LayoutView at (0,0) size 800x600
layer at (0,0) size 800x600
  LayoutBlockFlow {HTML} at (0,0) size 800x600
    LayoutBlockFlow {BODY} at (8,8) size 784x576
      LayoutBlockFlow {P} at (0,0) size 784x20
        LayoutText {#text} at (0,0) size 98x19
          text run at (0,0) width 57: "hjlkjld f . "
          text run at (57,0) width 41: "fd fads"
        LayoutText {#text} at (162,0) size 129x19
          text run at (162,0) width 4: " "
          text run at (166,0) width 125: "sdaf asd fasdf safsad"
layer at (8,8) size 64x16
  LayoutInline (relative positioned) {CODE} at (0,0) size 64x16 [bgcolor=#00FF00]
    LayoutInline {SPAN} at (0,0) size 64x16
      LayoutText {#text} at (98,3) size 64x16
        text run at (98,3) width 64: "filepath"
caret: position 21 of child 0 {#text} of child 0 {P} of body

# Layout Tree with position:relative (no background-color)
layer at (0,0) size 800x600
  LayoutView at (0,0) size 800x600
layer at (0,0) size 800x600
  LayoutBlockFlow {HTML} at (0,0) size 800x600
    LayoutBlockFlow {BODY} at (8,8) size 784x576
      LayoutBlockFlow {P} at (0,0) size 784x20
        LayoutText {#text} at (0,0) size 98x19
          text run at (0,0) width 57: "hjlkjld f . "
          text run at (57,0) width 41: "fd fads"
        LayoutText {#text} at (162,0) size 129x19
          text run at (162,0) width 4: " "
          text run at (166,0) width 125: "sdaf asd fasdf safsad"
layer at (8,8) size 64x16
  LayoutInline (relative positioned) {CODE} at (0,0) size 64x16
    LayoutInline {SPAN} at (0,0) size 64x16
      LayoutText {#text} at (98,3) size 64x16
        text run at (98,3) width 64: "filepath"
caret: position 21 of child 0 {#text} of child 0 {P} of body

LocalCaretRect() returns normal result for caret positions in CODE.

CaretDisplayItemClient::PaintCaret() is also normally called when the caret should be in CODE.

Since the caret is correctly painted when there's no background color, can the bug be caused by paint order?

Not familiar with paint code. My wild guess:

0. Let BASE be the main layer with P, and RELATIVE the other layer containing CODE

1. Blink associates caret to its containing block, and paint it with BlockPainter::PaintCarets(). In this issue, the containing block is P, which belongs to layer BASE, which means the caret is painted when painting BASE

2. After BASE (along with the caret) is painted, we paint layer RELATIVE, which contains the background color rect that fully covers the caret rect

So this is kind of an architecture bug -- the caret should be paint in layer RELATIVE, but it's incorrectly painted in BASE where its containing block is.

The reason range selection is painted correctly is that, range selection is painted by InineTextBoxPainter, which is always in the same layers as the text nodes.

Assigning back to yosin@, who knows more about caret painting.

Route to paint team per #c7.

Thanks for the analysis. We'll see how this evolves and get it fixed, I expect, when we are done with all the paint refactoring work. If not sooner.