Required VNC server to check this issue, hence adding TE-NeedsTriageHelp for further triage.

Thanks!

Reported again on twitter, here: https://twitter.com/el_jasoon/status/1021205133621907459 (same reporter both times)

Can you reach out to UltraVNC and see if they have any ideas? Most of our customers who do remote access to Windows machines use Microsoft's Remote Desktop Protocol and this seems to work reliably. I also found some other people who use VNC with Chrome without problems so this may be an UltraVNC bug, or quirk.

I'd be happy to work with the UltraVNC developers to try to understand what is going on. Because Chrome publishes its symbols and source (symbol server and source indexing makes downloading both of these automatic) they can attach a debugger to Chrome in order to diagnose why it is not behaving:
https://www.chromium.org/developers/how-tos/debugging-on-windows

An interesting update: I logged into my office machine using VNC this weekend, and Chrome exhibited the issue as usual.  I am now physically sitting at my office machine, and the issue is continuing.  So, in other words, I am seeing the issue right now even though I am not using VNC.

I can interact with the webpage that I was using in Chrome, but I can't click the address bar, bookmarks bar, the settings button, the minimize/maximize/exit buttons, new-tab button, etc.

I haven't seen this issue during a physical session until today.  I think the reason is that I usually close Chrome before exiting the VNC session.  This time, I left Chrome running after I exited the VNC session.

So, it appears that if the issue starts, it continues until Chrome is exited, with or without a VNC session.

As a test, I left the non-working Chrome session up and running, and I just started a new window of Chrome.  The new window correctly works and does not exhibit the issue.  The non-working Chrome window continues not working.

A video: https://youtu.be/_dkEIWj7ZeE

In the first part of the video, I click around in the broken Chrome window.  When I stop the cursor, I'm clicking on something.  You'll see that I can't interact with the "chrome" of Chrome.  In fact, even hovering over buttons has no effect.  This Chrome window was initiated within a VNC session.

In the second part of the video, I click around in the non-broken Chrome session.  I can fully interact with the window.  This Chrome window was initiated via a local console session (i.e., I was physically sitting at the computer when I started this Chrome window).

Just for kicks, I started a Hyper-V session on the computer while I was connected to the physical computer via VNC.  (In other words, I connected to the computer via VNC as usual, and I then started Hyper-V.)

As usual, I cannot interact with the chrome of Chrome on the actual computer, but I can interact with the chrome of Chrome in the Hyper-V session.  I guess in Hyper-V, Chrome doesn't know that my mouse cursor is "fake."

So, it's like if Chrome "thinks" that the mouse is a physical user, everything is fine, but if it "thinks" it's an automated/non-real user (like in VNC), then it prohibits access.

Does Chrome do any heuristics to determine if input is device- or API-driven?

More fun: I started a Chrome session while physically at the computer.

Then, I continued the session through a VPN connection.  Chrome continued working correctly.

So, based on this observation and the previous opposite observation, it appears that the issue is initiated by how Chrome is opened:

--If opened via VPN connection, Chrome is broken until closed
--If opened via physical/local console, Chrome correctly works until closed

It does not seem to matter how Chrome is interacted with *after* Chrome is started.  Switching from VPN to local console or vice-versa is irrelevant *after* the Chrome session is started.

*** UI Mass Triage **

We were unable to reproduce this bug. If this bug still reproduces for you, 
please reopen or file a new issue. Thanks!