Tested on chrome stable #55.0.2883.87, beta #56.0.2924.67 and Canary #57.0.2985.0 on Mac 10.12.2 and was able to reproduce the issue.

Below are the Bisect Details:
-----------------------------
Good build: 56.0.2888.0 (Revision: 424625)
Bad build: 56.0.2889.0 (Revision: 424926)

You are probably looking for a change made after 424789 (known good), but no later than 424790 (first known bad).

CHANGE-LOG URL:
---------------
https://chromium.googlesource.com/chromium/src/+log/8f1bc3342cf9167f24a03ea85c71f6212cca30f1..c0d0bd4e6f7e38c0208b78b2df9750ba7b0ceb0d

From the CL above, assigning the issue to the concern owner

@wkorman: 
------------------
Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Review-Url: https://codereview.chromium.org/2401363003

Note: Able to reproduce the issue in Win 7 & Ubuntu 14.04.

Can we assume |m_visualRect.contatins(drawingRect)| in CaretBase::paintCaret()?
Note: |m_visualRect| is updated in |CaretBase::invalidateLocalCaretRect()|

Some layout tests are failed. So, assertion |m_visualRect.contatins(drawingRect)| is failed some cases.
Is it OK to paint outside invalidate rectangle?

void CaretBase::paintCaret(Node* node,
                           GraphicsContext& context,
                           const LayoutRect& caretLocalRect,
                           const LayoutPoint& paintOffset,
                           DisplayItem::Type displayItemType) {
  if (DrawingRecorder::useCachedDrawingIfPossible(context, *this,
                                                  displayItemType))
    return;

  LayoutRect drawingRect = caretLocalRect;
  if (LayoutBlock* layoutObject = caretLayoutObject(node))
    layoutObject->flipForWritingMode(drawingRect);
  drawingRect.moveBy(paintOffset);
  DCHECK(m_visualRect.contains(drawingRect));

  const Color caretColor =
      node->layoutObject()->resolveColor(CSSPropertyCaretColor);
  IntRect paintRect = pixelSnappedIntRect(drawingRect);
  DrawingRecorder drawingRecorder(context, *this, DisplayItem::kCaret,
                                  paintRect);
  context.fillRect(paintRect, caretColor);
}

wkorman@ Gentle Ping! Could you please let us know is there any latest update available on this issue?

Thanks!

I can reproduce in Linux 58.0.3004.3 (Official Build) dev (64-bit) by visiting:

https://wikimedia.github.io/VisualEditor/demos/ve/desktop-dist.html#!pages/simple.html

and clicking in "was" to left of the linked "popularised" text, and then hitting right arrow until caret is just before the first 'p'. The caret ceases blinking while in this position but typing will insert text before the 'p'.

The caret blinks correctly even in this position in FireFox for comparison.

Re: c#6 I don't think it's ok to paint outside the invalidation rectangle. We recently modified caret invalidate/paint in https://codereview.chromium.org/2665823002 so I will make sure issue still repros at ToT as that change is not in current dev build.

These issues look fixed at ToT near certainly due to https://codereview.chromium.org/2665823002. Congrats to author of that change. We can consider merging to M57 if we feel warranted, though I would personally suggest waiting for it to ship normally in M58. The fixing change is not trivial. Open to thoughts.

I also think we should wait. Either just wait for m58, or wait after a few canary/dev builds and merge to m57 if we see no problems.

Marking fixed, any build after r448799 should be fixed. 58.0.3006.0 was the first version to include that change.