This is a known bug in Chrome Stable. It has been fixed and you should receive the update shortly, or you can switch to Chrome Beta if you don't want to wait.

I have the same problem on both my corp and personal mac hosts, when connected from both the Chrome app and iOS client. However my Linux host and Windows host doesn't have this issue. I suspect it's a bug on the Mac host?

My host log doesn't show anything interesting: https://paste.googleplex.com/4947164211970048

(Maybe I'm not getting all the logs. These are just logs copied from the console filtered by the process name. The log collection instruction has long been broken.)

The problem is still reproducible with a Mac client installed with Chrome Canary 67.0.3384.0 connected to a Mac host started with the same Chrome Canary.

I don't know what version my host is since `remoting_me2me_host --version` just returns the string "VERSION", but I suspect it's 66.0.3359.12, and my macOS version is 10.13.3 (17D102).

It's a regression introduced some time between the previous release (65.0.3325.39) and the current one (66.0.3359.12). I'm investigating.

I've narrowed it down to between 66.0.3341.0 and 66.0.3343.0. Currently having trouble getting git bisect working to narrow it down further.

The regression seems to have been introduced in https://chromium-review.googlesource.com/681850

rsesek, can you suggest how we can work around this? It's making CRD on Mac unusable but we missed it in our testing so we need to release a fix ASAP. I can't see how we can selectively revert to using MessagePumpCFRunLoop for remoting; can https://chromium-review.googlesource.com/681850 be reverted?

I think it's probably risky to revert that on M66 at this point. There's not a lot of information here to debug (is it host side, guest side, etc.) and I know little about the remoting architecture…

My guess is that something in remoting was relying implicitly on a non-main thread having a CFRunLoop-backed MessagePump. Likely it would be an OS resource that is installed as a CFRunLoop source, and that stopped working. If this is the case, then simply starting the thread with an explicit TYPE_UI MessageLoop would work (it's a base::Thread option here: https://cs.chromium.org/chromium/src/base/threading/thread.h?q=TYPE_UI%5Cb&sq=package:chromium&dr=C&l=71).

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

commit 1ac41f213ba266368cc4207a3b5ca884961878fc
Author: Jamie Walch <jamiewalch@chromium.org>
Date: Thu Apr 05 01:08:58 2018

Use a UI thread for capturing on macOS.

https://chromium-review.googlesource.com/c/chromium/src/+/681850 changed
the default run loop on Mac, which broke our capturer (it started
returning zero-size frames for all but the initial capture). I'm not
sure what our dependency on MessagePumpCFRunLoop is, but switching to a
UI thread means that the capturer has access to one again.

Change-Id: I9ac8ac19f325f88f9e758613f50ac2a2a00dc01d
Bug:  827300 
Reviewed-on: https://chromium-review.googlesource.com/996296
Reviewed-by: Joe Downing <joedow@chromium.org>
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548278}
[modify] https://crrev.com/1ac41f213ba266368cc4207a3b5ca884961878fc/remoting/host/chromoting_host_context.cc

Thanks for fixing, and sorry for the breakage.

Assuming I've traced things correctly, the ScreenCapturerMac runs on the video_capture_task_runner. ScreenCapturerMac adds a CFRunLoop source in this function at line 533: https://webrtc.googlesource.com/src.git/+/448f4d50dc75531db755ed6829f33be426429f95/modules/desktop_capture/mac/screen_capturer_mac.mm#489. What's a little tricky is that nothing in this code will fail: using CFRunLoopGetCurrent() will lazily create the thread-local runloop and the source will install on it successfully. The issue was that the loop was not getting run at all, since the MessagePump/TaskRunner is driven by a different OS primitive that doesn't process CFRunLoop work.

Thanks for your help with both the bisect and the pointers on how to fix; it would've taken me a lot longer without that.

Just wondering, fox this fix should I upgrade chrome or chromote remote desktop app on my host?  I just checked right now and it seems I still get a frozen session.

Tried checking the issue on reported chrome version 65.0.3325.181 and on the latest canary 67.0.3390.0 using Mac 10.13.1  and Ubuntu 14.04 as remote system.
1. Launched Chrome
2. Installed the extension from https://chrome.google.com/webstore/detail/chrome-remote-desktop/gbchcmhmhahfdphkhkmpfmihenigjmpp?hl=en
3. Signed into remote computer and installed the extension.
4. Clicked on Access on Mac and Share on Ubuntu, later entered the access code from remote system in Mac, Clicked on connect.
5. Accepted the request from remote system.
After loading for some time it says, "unable to reach the host". Attaching the screen shot of the same.
Note: Using Mac with Wifi and Ubuntu with LAN connection.

@Jamie Walch: Could you please let us know if we have missed anything from our side. It would be highly helpful if mentioned whether the environment in which we are testing makes any difference.

Thanks! 

Deleted: 827300.png 539 KB

	827300.png 539 KB View Download

lepton@: We have rolled back the affected version of Chrome Remote Desktop so you should get an update soon. You can also run the following command to force an update immediately:

/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/CheckForUpdatesNow.command

Adding on to Jamie's comment, you *may* need to restart the host service (you can use launchctl or just restart the machine).

The longer version of this is that during the rollback we found an installer script issue that wasn't properly stopping the host service on package install.  The install will succeed but the host running would still be the broken version.  A machine restart or service stop/start *should* fix the problem if you are in that condition.

Indeed, restart chromoting make it work now. Thanks a lot!