Two more observations:
- 'progress' and 'wait' cursors are not mirrored: https://youtu.be/E1jImZGifbQ
- custom cursors cursor: url(...) are not mirrored: https://youtu.be/TUuZ3-uPUTg

regarding #1:
custom cursors are now rendered in 52.0.2715.0 (tested on OSX).

Unable to repro this issue on Ubuntu Trusty (14.04) for Google Chrome Stable Version - 50.0.2661.94

Screen-recordings are attached.

@thembrown: Could you please perform the steps mentioned beneath and let us know your observations.

1. Update your Google Chrome to Latest Stable Version - 50.0.2661.94
2. Re-test the same on a clean profile [chrome://settings -> Add Person]

Thank you.

Deleted: 601029.ogv 2.7 MB

601029.ogv 2.7 MB Download

Deleted: 601029 - 1.ogv 1.5 MB

601029 - 1.ogv 1.5 MB Download

Hi, sorry. My description was a bit imprecise. The rendering in Chrome is fine in all cases - just the cursor rendered in the media stream obtained by the tabCapture API is broken.
An easy way to reproduce would be to cast the content of the tab to a Chromecast (using the Google Cast extension).

Just re-checked on 50.0.2661.75 with an mew/empty profile directory. Still able to reproduce:
https://youtu.be/ZYvzZhW_qIs

If you don't have a Chromecast at hand, you could also use 
https://chrome.google.com/webstore/detail/screencastify-screen-vide/mmeijimgabbpbgpdklnllpncmdofkcpn?hl=en with Tab recording.
It applies a workaround for this issue through a injected content-script in the meanwhile, but it'll still record chrome-internal pages like chrome://version AS-IS where content-scripts cannot be injected. That's what I used to record those videos. However I'm also able to reproduce it the same way with tab-mirroring using Google Cast.

Sidenote: It seems that the cursor mirroring implementation ( https://crbug.com/550555 ) always assumes that cursors are anchored at the to-right corner. Which causes non-arrow cursors like the caret to be positioned incorrectly and jump around.

Thank you for providing more feedback. Adding requester "rnimmagadda@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@isheriff: Could you please look into this issue and let us know if this related to the issue - 550555 ?

Thank you.

"anchored at the to-right corner" should read:
anchored at the top-left corner (i.e. 0,0 in CSS "cursor:" coordinates)

Thank you for providing more feedback. Adding requester "rnimmagadda@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

What is the use case for mirroring cursor without the tab in focus ? I think that is intentional at this point.

Lets keep this bug to track the inaccurate carret display. 

I don't have a real use-case for this, I was just confused to see an accidentally un-focused tab repond to mouse (hover) events as usual without seeing the cursor mirrored.
Admittedly this is probably not very important in practice.

I see this at home on my Windows machine as well. I think comment #6 accurately explains the problem.

qiangchen: Since you recently worked on a mouse cursor rendering bug, would you be willing to take this on? Should be a simple math/position adjustment, taking into account the hot point coordinate of the cursor?

I can take a look. But I do not think #6 explains correctly, as by code reading, I found hot point processing explicitly. So there must be something else.

Bumping to M57. Please update if that's wrong.

With the fix to  issue 676687 , this issue should be fixed now. Please try with Canary on Win or Chromium ToT (M57 and later)on Linux. 

dbbrooks: Can you please perform verification testing of tab mirroring cursor rendering with Chromecast? The following cursor issues (i.e., how the cursor is rendered on the Chromecast) should be gone on all of Win+Mac+CrOS:

1. The hot point of the cursor should be accounted for. That means for an arrow, the click point is the tip of the arrow; for the text caret, the click point is approx. the middle (vertically) of the text caret; for the pointy hand (over buttons), the click point should be at the tip (or a little bit underneath) the finger. You can determine this by slowly moving the mouse into and out of text boxes or buttons on a page.

2. The various cursors should be rendered correctly (i.e., correct graphics). On Windows, the text caret used to be semi-invisible; but that was a bug. It should look just like what the user sees on the local screen; or a suitable substitute.

3. The position of the cursor is correct regardless of the browser window size. So, please try resizing the browser window randomly and make sure the cursor on the Chromecast corresponds to what you see on the local machine (e.g., if pointing at the first letter of a sentence, it should be the same on the Chromecast).

4. The position of the cursor should be correct whether using a high-DPI (e.g., Retina) display or not, regardless of browser window size.

Thanks!

I still need to test retina and CrOS, but here's an update since I hit an issue.

The text caret is invisible on Win (well it's rendered in white I think). Win 57.0.2978.0 {#442756}

Just finished, CrOS and Mac (+ retina display) look good. It's just the issue mentioned in #19. So I can't mark this as verified yet.