I'm sure other operating systems have this kind of facility - after all, how does the built in text edit control draw its caret?
[0] https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
The "built in text edit control" IS a native text field already.
No need to have an official OS caret function (especially if you're not a native text field, and caret aside, the rest of your text editing will be different/broken in subtle ways compared to the OS).
Certainly, on the original Mac OS (a system on which I worked on OS patches for detecting the location of the caret) the method that application used for drawing the caret varied widely. I've seen it implemented by drawing a line, by drawing a rectangle, either in one go or in two parts (that happened in applications that supported a split caret, even if the caret wasn't split), with various transfer modes. Slanted carets typically were application-specific, too.
Windows allows this. In a parent comment I posted a link to the API docs. All Windows requires is a window to hold the caret, it doesn't care what kind of window it is.
I'm guessing the culprit for that is in this part of the bug report:
> Zooming into a single frame, we see that while we render only 2 fps, the main thread is performing some work at 60 fps (every 16 ms)
As for
> why they needed to implement it themselves and not let the OS handle the blinking cursor
They're not editing inside a text editor field anymore, they need to blink on html. I guess they're not using a deprecated <blink> tag is because it's not customizable in any way.