bug: windows-rdp auto-fill no longer submits the form on Devolutions Gateway 2026.2.x

[matifali]

Current Behavior

The windows-rdp module defaults to devolutions_gateway_version = "latest", which currently installs Devolutions Gateway 2026.2.4. The module's devolutions-patch.js selectors no longer match that UI, so the sign-in form is filled but never submitted, and no session starts.

Observed on a live AWS Windows workspace, browser console:

[Devolutions Patch] Form detected. Starting auto-fill...
[Devolutions Patch] Protocol dropdown trigger not found.
[Devolutions Patch] Hostname set to localhost
[Devolutions Patch] Set username to Administrator
[Devolutions Patch] Set password to <redacted>
[Devolutions Patch] Submit button not found or disabled.
ERROR TypeError: C.protocol.toLowerCase is not a function
    at A.socketOnMessage (.../chunk-AKNLUDAU.js)

The form stays on screen with the fields populated, the session-toolbar never appears, so attachCloseListener, Unicode Keyboard Mode and Dynamic Resize never get applied either.

Two selectors have drifted:

• p-dropdown[id="protocol"] no longer matches the protocol control
• p-button[class="p-element"] button no longer matches the connect button

Expected Behavior

Opening the Web RDP app connects straight into the Windows desktop, with no visible form and no manual click.

Steps to Reproduce

1. Add the windows-rdp module to a Windows workspace, leaving devolutions_gateway_version at its latest default.
2. Start the workspace and open the Web RDP app.
3. The Devolutions form appears pre-filled, but no session connects.

Desired Solution

Update the selectors in devolutions-patch.js for the current Gateway UI, and make the failure loud rather than silent: if the submit button cannot be found after N polls, surface a visible message instead of only logging to the console. A user today just sees a form that does nothing.

Worth discussing separately: latest means an upstream UI change can break every workspace using this module with no change on our side. Pinning a known-good default and bumping it deliberately would trade freshness for predictability, which seems like the right trade for an air-gapped or otherwise change-averse deployment.

Note

Found while dogfooding #1034. Independent of the credential escaping fixed there.

Related to #20

🤖 This response was generated by Coder Agents.

[linear-code]

ENG-3155

[matifali]

Pinned down the exact selector drift on Gateway 2026.2.4, via CDP against a live workspace.

The current UI renders:

{
  "p-dropdown[id=\"protocol\"]": 0,
  "p-button[class=\"p-element\"] button": 0,
  "p-select": 2,
  "p-button": 2,
  "buttons": [
    { "text": "New Session", "classes": "p-ripple p-button p-component" },
    { "text": "Connect Session", "classes": "p-ripple p-button p-component" }
  ]
}

So both patch selectors miss:

Patch looks for	Current UI
p-dropdown[id="protocol"]	p-select (PrimeNG renamed the component)
p-button[class="p-element"] button	button.p-ripple.p-button.p-component, label Connect Session

The exact-match class="p-element" selector is the fragile part. It breaks on any class list change.

Confirmed the rest of the flow is fine: clicking Connect Session manually connects straight into the Windows desktop with the auto-filled credentials, ironrdp web::session: Connected!. Only the auto-submit is broken.

Also worth noting, the Angular app takes longer to render the form than it used to. The patch found the form at roughly 7s in one run and not until past 20s in another, so whatever replaces the current polling should keep a generous ceiling.

🤖 This response was generated by Coder Agents.

[matifali]

More drift, found by inspecting a live session over CDP. The breakage is wider than the submit button, and every bit of it fails silently.

Patch selector	Status on 2026.2.4	Replacement
p-dropdown[id="protocol"]	gone, PrimeNG renamed the component	p-select#protocol, or drop it, RDP is already the default
p-button[class="p-element"] button	gone, class list is now p-ripple p-button p-component	button[type="submit"] scoped to web-client-form form
session-toolbar	gone	floating-session-toolbar, inside rdp-toolbar-wrapper
setCheckbox("Unicode Keyboard Mode")	label no longer exists	n/a
setCheckbox("Dynamic Resize")	now Enable Dynamic Display Configuration (Display Control), and it lives on the connection form, not the toolbar	set it during form fill

Consequences today: the form fills but never submits, and even after a manual click pollForSessionToolBar never resolves, so the close-window listener is never attached and neither checkbox is ever applied. That poll also loops every 500ms forever.

Suggested shape of the fix:

1. Prefer structural and semantic hooks over class lists. button[type="submit"] inside the form, and the existing web-client-* custom element names, have been stable across versions. Exact-match class="p-element" was always going to break.
2. Give both polls a bounded number of attempts, then surface a visible message and reveal the form, instead of logging to a console nobody has open.
3. Move the display-configuration checkbox into fillForm since it now lives on the form.
4. Reconsider devolutions_gateway_version = "latest" as the default. An upstream UI change silently breaks every workspace using this module.

🤖 This response was generated by Coder Agents.

[matifali]

Folding this into #1034 rather than a separate PR. Nothing is published yet, so shipping the credential fix alone would release a 1.3.1 whose passwords are correct but which still doesn't auto-connect on latest Gateway. One release that works beats two.

Selector fixes verified unattended against a live workspace, no clicks:

[Devolutions Patch] Form submitted.
[Devolutions Patch] Top bar detected. Proceeding with next steps...
[Devolutions Patch] Close listener attached.
canvas: 1   floating-session-toolbar: 1   failure banner: 0

The latest default is still open for discussion and is not addressed by that PR.

🤖 This response was generated by Coder Agents.