Chrome Remote Desktop fails to update the contents of desktop
Reported by
tri...@gmail.com,
Apr 9 2018
|
|||||||
Issue descriptionChrome Version: 66.0.3359.79 OS Version: 10452.42.0 What steps will reproduce the problem? 1. from ChromeOS, Android, or macOS -- open a CRD connection to a macOS (10.13.4) machine that has CRD installed and shared 2. connects successfully but desktop contents do not update correctly -- most windows are red, mac menus lack any text, etc... 3. see screenshot UserAgentString: Mozilla/5.0 (X11; CrOS x86_64 10452.42.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.79 Safari/537.36
,
Apr 10 2018
,
Apr 10 2018
AJ, can you install the 10.13.4 update and run a test pass, please?
,
Apr 10 2018
Jamie, with this update installed and the machine as host, the screen does not update at all after the initial connection. On the client, you can see the desktop, but there is no visible interaction or screen refresh. On the host, the mouse can be seen moving around to mirror the client mouse moves.
,
Apr 10 2018
Can you confirm the version of CRD host and verify that the same version of Chrome can be used to connect to a different host OS successfully (just to eliminate the two recent no-update bugs)?
,
Apr 12 2018
#5 is this something I can do? I am not certain how to tell which version of CRD (host) is installed on any of my Macs. Also, is there a way to force the service to upgrade/pull down the newest version if I am stuck behind?
,
Apr 12 2018
Hi Jamie, it turns out this behavior only occurred when the Mac is headless. And after a reboot and chrome update, the behavior changed. Interaction occurs on the client, and actions can be performed, but white blocks cover large portions of the screen, so you can't see what you're doing. The mouse pointer is visible, and portions of the desktop are as well. When connected to a monitor, things appeared normally. I'll run a test pass with this machine as host. Host version is 65.0.3325.39 and I could not repro this connecting to other hosts, headless or no.
,
Apr 12 2018
triune@gmail.com: Was your Mac running without a monitor attached?
,
Apr 12 2018
Yes, both my Mac Pros are headless servers... Only the 10.13.4 one is experiencing this issue tho.
,
Apr 12 2018
Thanks. It sounds like an OS regression for the headless use-case. AJ, can you repro and then capture a sysdiagnose report (https://download.developer.apple.com/OS_X/OS_X_Logs/sysdiagnose_Logging_Instructions.pdf) so we can report the issue to Apple?
,
Apr 13 2018
Jamie, I emailed you report, captured on the host while running headless. The file is too large to attach
,
Apr 14 2018
I have filed https://bugreport.apple.com/web/?problemID=39428839 with Apple.
,
Apr 17 2018
,
Apr 19 2018
I have an Apple developer account, but cannot view the bug report from the link provided. I'd like to track the progress of this issue since the workaround for me at this point is to keep a monitor connected to my headless machine until it is fixed. Possible to give me access to that bugreport? Otherwise, will this ticket be updated when it is resolved since this issue now has no owner?
,
Apr 20 2018
I couldn't find any way of sharing the report, but in my experience they don't tend to receive regular updates so I don't think you'd get much benefit from following it anyway. I'll keep this bug open until I hear about a resolution.
,
Jun 4 2018
...was hoping that the 10.13.5 update would solve this issue. However, the problem persists even after this update is applied.
,
Jun 12 2018
This was reproducible for us with 10.13.4, but we can no longer repro as of 10.13.5. Can you confirm that that's the version you're running? Does the failure mode still look like your screenshot in the original bug report, or more like the one we attached in comment #12?
,
Jun 12 2018
Just updated to 10.13.5 but no change, the problem persists. I'm getting the exact same issue as shown in the screenshot from comment #12: blanked out menus and screens. I'm connecting from Windows 10 to a headless mac mini server.
,
Jun 12 2018
Here's a screenshot from 10.13.5 >> As you can see, Finder windows appears correctly; the menubar is missing all text; some windows are red filled; other windows only have their shadow drawn.
,
Jul 18
Updated my Mac Mini Server to 10.13.6 but the problem is still there. Menus are blanked out (see screenshot) and the mouse pointer has a white square behind it. I'm connecting from a fully updated Windows 10 (64 bit) machine with Chrome Version 67.0.3396.99. My best bet is now MacOS Mojave. Did someone had a chance to test this problem on the Mojave beta? (I can't run betas on my Mac)
,
Jul 24
I've just updated (finally) to High Sierra v10.13.6 and am having the exact same issues as onlinety. The picture in the last comment is what I'm seeing.
,
Jul 24
Like most others had advised, reinstalling and rebooting seems to have fixed it for now.
,
Jul 26
Having the same issue exactly as described by previous users. Can also confirm with our Mac lab that 10.13.4 and above have this issue. Our other Mac Mini's running 10.13.1 and headless do not have this behavior. We have tried clean installs of OS on problem Mac but our earliest version is currently 10.13.4 so the issue persist after imaging. Additionally, found that as long as a recognized adapter is plugged into the "headless" Mac Mini, it will recognize it as a display profile and the issue will stop. Once the adapter is removed the issue returns. First image is the color profile with a Mini Display to VGA adapter plugged in. Second image is Mac Mini with nothing hooked up to display adapters. Third image is the Mac Mini OS information.
,
Sep 11
A clean install did NOT fix the issue for me. However, I did find a hardware solution that works for my headless mac mini. The problem is in the word 'headless': as long as the mac thinks it has a monitor connected to it, the problem disappears. I could only solve this by using a hardware solution in the form of a HDMI Headless Emulator Plug (see image). This simple plug tricks the mac into believing it has a real monitor connected to it. I bought one for $7, plugged it in while connected through CRD (with the erratic screens similar to the ones in Comment 25) and voila: the problem instantly disappeared! I also found a homemade version, with a 75 Ohm resistor plugged in straight into a Thunderbolt to VGA adapter. I did not test this solution. While this hardware solution works for me, I still believe there should be a software based solution. In others words: this is still a bug, although a $7 dollar plug that fakes a monitor might do it for now...
,
Oct 8
I have just installed a fresh copy of OS X Mojave (10.14) and I'm now seeing this issue when connecting from a Windows 10 client to a headless server. I see an initial update of the screen, and then white blocks appear wherever the mouse moves. Some interactions make the screen update (such as clicking on a window or dragging one around). I have an HDMI switch connected between my Mac and the monitor and the instant I switch to the Mac, the screen begins to update normally. Switching away from the Mac usually makes the issue reappear, although by repeatedly switching back and forth I can get the Mac in a state where the monitor is not switched through, but the display is still being updated.
,
Oct 15
Since Apple did not fix this issue with 10.14 ... I couldn't wait any longer. So, I picked up two of these: https://www.headlessghost.com and they solved the problem brilliantly on both of the Mac Pro's I use them on! Check out the available display resolutions and HDMI Audio sinks these things provide! |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by tri...@gmail.com
, Apr 9 2018