Remote Desktop URL Forwarder — is `remoteOpenUrl` available in the public web client?

[Greg Steuck]

Hi,

I'm trying to use the Chrome Remote Desktop URL Forwarder feature on a Debian 13 Linux host (GCE VM, me2me mode). The host package (version 146.0.7680.5) ships `remote-open-url`, `configure-url-forwarder`, and `crd-url-forwarder.desktop`. The forwarder is properly set up:

```
$ /opt/google/chrome-remote-desktop/configure-url-forwarder --check-setup
Chrome Remote Desktop URL forwarder is properly set up.
```

However, running `xdg-open https://example.com` always results in:

```
[greg@greg-pvm:~$ xdg-open https://example.com
[0307/230342.566809:INFO:remoting/base/crash/crashpad_linux.cc:68] Crashpad handler started.
[0307/230342.568588:WARNING:ui/base/resource/resource_bundle.cc:526] locale_file_path.empty() for locale
[0307/230342.568713:INFO:remoting/base/file_host_settings.cc:49] Host settings loaded.
[0307/230342.605430:WARNING:remoting/host/remote_open_url/remote_open_url_client.cc:159] IPC disconnected.
[0307/230342.605460:WARNING:remoting/host/remote_open_url/remote_open_url_client_delegate_linux.cc:127] Unknown desktop environment: , X-Generic will be used.
[0307/230342.605467:WARNING:remoting/host/remote_open_url/remote_open_url_client_delegate_linux.cc:134] Fallback browser is invalid. Showing the browser chooser...
[0307/230342.605483:WARNING:ui/base/resource/resource_bundle.cc:1266] locale resources are not loaded

(remote-open-url:351499): Gtk-WARNING **: 23:04:12.492: gtk_widget_size_allocate(): attempt to allocate widget with width -6 and height 48
```

The `remote-open-url` client connects to the Mojo IPC socket at `/tmp/chromoting.<user>.host_services_mojo_ipc`, but the host immediately drops the session services binding. A CRD viewer is actively connected at the time.

After tracing through the Chromium source, I believe the issue is on the client side:

1. In `remote_open_url_util.cc`, `IsRemoteOpenUrlSupported()` unconditionally returns `true` on Linux. The `allow_uri_forwarding` policy defaults to `true`. So the host correctly advertises `kRemoteOpenUrlCapability`.

2. In `client_session.cc`, the host registers the `RemoteOpenUrlMessageHandler` data channel **only** when the connected client also advertises `kRemoteOpenUrlCapability` during capability negotiation:

   ```cpp
   if (HasCapability(capabilities_, protocol::kRemoteOpenUrlCapability)) {
       data_channel_manager_.RegisterCreateHandlerCallback(
           kRemoteOpenUrlDataChannelName, ...);
   }
   ```

3. If the client doesn't advertise this capability, the handler is never registered, and the host rejects the `remote-open-url` Mojo IPC binding — producing the "IPC disconnected" behavior.

I'm connecting from the public web client at remotedesktop.google.com (via ChromeOS). The session options panel has no "Open links on the client" toggle or URL forwarding setting. The code review discussion at [ab_m9yyEAvc](https://groups.google.com/a/chromium.org/g/chromoting-reviews/c/ab_m9yyEAvc) mentions the host checking "if the user is a Googler" to gate the feature, and that "the client can be later modified to always enable the feature."

My questions:

1. Is the `remoteOpenUrl` capability currently advertised by the public CRD web client at remotedesktop.google.com? Or is it only enabled for internal users?

2. If it's not yet public, is there a timeline for enabling it? The host-side infrastructure has been shipping in the Linux package for several years.

3. Is there a workaround or client-side flag to enable this capability?

Thanks for any guidance.

[Pratyush Mohanty]

Hi Greg,

Your analysis of the capability negotiation is consistent with how the feature is implemented: the Linux host only enables the RemoteOpenUrlMessageHandler when the connected client advertises kRemoteOpenUrlCapability. If the client does not advertise it, the host will not register the data-channel handler and the Mojo binding from remote-open-url will be dropped, resulting in the “IPC disconnected” behavior you are seeing.

Regarding your questions:

1. Public web client support: The public Chrome Remote Desktop web client at remotedesktop.google.com does not currently expose URL forwarding as a generally available end-user feature, and in that configuration it should not be assumed to advertise kRemoteOpenUrlCapability for all users/sessions.

2. Timeline: I do not have a reliable public timeline to provide for enabling this capability broadly in the public web client.

3. Workaround / flag: There is no supported client-side flag in the public web client UI to force-advertise this capability. Practically, the only workaround in the public client is to continue using copy/paste (clipboard) to open links locally, or open the URL within the host session’s browser.

I am checking with the relevant engineering contacts to confirm the current gating status and whether there is any sanctioned path (or upcoming change) for broader availability. I will follow up within 24 hours with what I find.

Regards,
Pratyush Mohanty

Email sent via Mail Agent