miu@ is this a known issue?

I have been able to reproduce this with a desktop capture recording on my own computer pretty recently:

https://www.opentest.co/share/d0850fd09fbf11e6abfecb3b80bafc66

since you say desktop capture, can you clarify whether you use chrome.tabCapture or chooseDesktopMedia? The actual capture path should be the same though. Possibly related to https://bugs.chromium.org/p/chromium/issues/detail?id=656018

#3: In that recording, I used chooseDesktopMedia. But I've seen this surface for our users more often in chrome.tabCapture. Reproducible in both though.

Here's another video from a user:

https://www.opentest.co/share/54ae1a10a13a11e68e5b7163458686ee

OS X 10.12.1
54.0.2840.71

As with the other user, let me know if you'd like to email him directly.

Brave, can you take a look and see if you can figure out what's going on?

We can see the problem on OSX10.12, meanwhile OSX10.11 shows no problem. It happens to all the screen capture types.
I'll check of there is any API changes in Sierra.

#7: sweet :-) thanks for the update!

 Issue 661402  has been merged into this issue.

 Issue 656018  has been merged into this issue.

@Brave do you have any idea which version this would land into once the fix is made? Just wondering if there's any way to make this a hotfix into a minor or patch version of 54/55.

#12 - it will land in the latest version on trunk (currently 56, but may change until the fix is landed).
Merges to stable usually happen given a combination of a few factors, for example -
- It is a critical issue.
- It affects a lot of users.
- It is safe and/or small enough (a one-line, isolated change, for example).

It is probably not critical (it is not a crash, a security issue, or a popular website that fails to be functional) and I can guess it does not affect a lot of users (since it is an extension API and it is a macOS specific issue, right?).

The fix itself will perhaps determine whether this will be merged, but I would not count on it.

@Brave: I reported another Mac tabCapture cursor issue here  https://crbug.com/606300  a while ago. Not sure if this is related though, it only seems to affect hdpi resolutions. 

This problem should only happen on Mac 10.12(Sierra) with Retina screen. Apple seems made a fix to a Retina display issue, which broke the logic in Chrome tab capture.
Since Chrome M55, the screen capture and Window capture should work again on Sierra with Retina, due to the fix to another issue, https://bugs.chromium.org/p/chromium/issues/detail?id=632995. I'll see what we can do to tab capture. And as comment #13, it most probably won't be merged into Stable/Beta. Try to stay with Window capture instead for a while.

#13: What constitutes a lot of people? This is affecting a large percentage of our Mac users since Mac users tend to update to the latest OS version more readily than Windows users (new OS updates are free on OSX usually). We have about 27k users and I believe 8k of them are on Sierra. This bug renders a lot of use cases for our screen recorder useless since people can't see where someone is pointing.

Honestly though, forget our screen recorder. Screencastify is a screen recorder with 2.7m users. I can't imagine that any less than 100k of those users is on Sierra at this point and this bug, once again, would render their paid software ineffective for many use cases.

#15: Desktop/window capture does not seem to fix the issue.

It would be awesome, if this fix is small enough, if we could get this hot-patched. An entire 2 Chrome versions of waiting is enough time to seriously put a dent in our adoption as a small startup. :-\

#16 - 8,000 users (out of over a billion users) are not a lot of people, I believe. More like... 800,000 people. :(

#17: the problem is that, if you continue down that line of thinking, you tend to push away legitimate up-and-coming developers who have their efforts thwarted by bugs. The smaller the team and user base, the more important time is to them and the larger the impact of a bug like this one.

Again, only bringing this up because this is actually a fairly large issue for us as a small team and we'd want to stay on the Chrome platform even when we have a full desktop recorder. It just makes me a little weary knowing that something small but large like this could break and then we're kinda SOL until it gets fixed a complete two major versions down the road. I completely understand that you may not be the decision-maker here which is why I was just asking if there were hard numbers on when we could potentially ship this as a hot patch to either this version or to roll into the next.

#18 -

Personally, I totally understand your position.

Not only am I not a decision maker, I am not even on the Chrome team. I just told you what I have seen happening up until now. If they do not impact a lot of users, fixes are generally not merged.
Do not forget that every hotfix can, unfortunately, also bring new bugs (they may even not be actual code bugs, but compiler bugs that cause runtime bugs as a result of, for example, code being shifted to somewhere else - this happened multiple times), so the team tries to keep them to a minimum. The burden on users is just too high.

Yeah totally understand. Thanks for the clarification - I appreciate it. Not sure why I didn't even realize you're not on the Chrome team.

vinay: Unfortunately, yes, the issue is that there are never enough developers to work through every bug; and so we have to prioritize efforts. But, Chromium is an open-source project: If this issue makes/breaks your business, you can certainly have one of your developers root cause the issue and submit a code review with the fix. We always welcome that. :)

#21: Haha I'm intimately familiar with limited time and infinite bugs. We only have two devs (including myself). :-P

Available + owner --> assigned

As an update, Desktop cursor seems to have come back in Chrome 55 but tab is still missing:

Tab:

https://www.opentest.co/share/56f16040c87f11e6abf79735dfd95770

Desktop:

https://www.opentest.co/share/687c09a0c87f11e6abf79735dfd95770

cl is uploaded for review already. 

Gah I see.

So can someone please confirm if this bug is fixed? I'm using desktopCapturer API from Electron, which is based on this API and cursor does not appear. 

The status is not "Fixed", so, no, it was not fixed in any recent version.

#27: This is regarding tabCapture (not chooseDesktopMedia). That being said, desktop capture does appear to be working again for our Chrome extension since Chrome M55.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2f9c8630f029d251af62445f88357d0edbf0543c

commit 2f9c8630f029d251af62445f88357d0edbf0543c
Author: braveyao <braveyao@chromium.org>
Date: Fri Jan 06 18:06:28 2017

Fix cursor missing in tabCapture on OSX Sierra

Since OSX Sierra, when we ask for the CGImage of a cursor image, it will return
a double-size CGImage with Retina display, which can't pass the sanity check.

=========================(deprecated)==================================
In this cl, we try to pass a half-size Rect hint to get CGImage with original
cursor size on both Retina and non-Retina display.
Also it fixs another issue that we render the cursor based on window coordinate
to a target in physical coordinate.
======================================================================

In this cl, we implemented a new common base class, CursorRenderer , to
merge the two implementations. Then we can handle the scaling and
rendering of cursor same on all platforms, also with other advantages:
caching scaled cursor image for better performance and only caring
about view coordinates (same handling to Retina and non-Retina).

BUG= 659183 

Review-Url: https://codereview.chromium.org/2553763002
Cr-Commit-Position: refs/heads/master@{#441975}

[modify] https://crrev.com/2f9c8630f029d251af62445f88357d0edbf0543c/content/browser/BUILD.gn
[modify] https://crrev.com/2f9c8630f029d251af62445f88357d0edbf0543c/content/browser/media/capture/aura_window_capture_machine.cc
[add] https://crrev.com/2f9c8630f029d251af62445f88357d0edbf0543c/content/browser/media/capture/cursor_renderer.cc
[modify] https://crrev.com/2f9c8630f029d251af62445f88357d0edbf0543c/content/browser/media/capture/cursor_renderer.h
[modify] https://crrev.com/2f9c8630f029d251af62445f88357d0edbf0543c/content/browser/media/capture/cursor_renderer_aura.cc
[modify] https://crrev.com/2f9c8630f029d251af62445f88357d0edbf0543c/content/browser/media/capture/cursor_renderer_aura.h
[modify] https://crrev.com/2f9c8630f029d251af62445f88357d0edbf0543c/content/browser/media/capture/cursor_renderer_aura_unittest.cc
[modify] https://crrev.com/2f9c8630f029d251af62445f88357d0edbf0543c/content/browser/media/capture/cursor_renderer_mac.h
[modify] https://crrev.com/2f9c8630f029d251af62445f88357d0edbf0543c/content/browser/media/capture/cursor_renderer_mac.mm
[modify] https://crrev.com/2f9c8630f029d251af62445f88357d0edbf0543c/content/browser/media/capture/web_contents_video_capture_device.cc

@brave: nice code land! Seems like this will likely fix a lot of the cursor issues. Anyone have any idea when this will land?

Multiple issues of tab capture have been addressed, i.e.  issue676687 , and all platforms are benefited. 

The fix will be released in M57. Not quite sure if if will be merged to M56.