UI: Copy from workflow logs using Ctrl-C doesn't work on Linux & Windows

[Joibel]

Pre-requisites

• I have double-checked my configuration
• I can confirm the issue exists when I tested with :latest
• I have searched existing issues and could not find a match for this bug
• I'd like to contribute the fix myself (see contributing guide)

What happened/what did you expect to happen?

This is a reproduction on firefox 124.0.2 on linux/gnome/wayland of a bug report from windows. I have reproduced it using other window managers and browsers on linux too. I have been informed this works fine on MacOS, which may be down to copy being Cmd+C rather than Ctrl-C there.

In pod logs in the user interface is it not possible to use Ctrl-C to copy the logs. This is demonstrated here:

https://drive.google.com/file/d/1PGk6Y7RRyvg4vppxuhpJUYcjubYf-A91/view?usp=drive_link

Right click copy works.

Version

v3.5.5

Paste a small workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.

Not relevant

Logs from the workflow controller

Not relevant

Logs from in your workflow's wait container

Not relevant

[Joibel]

Tagging @Adrien-D to work on it

[agilgur5]

I have been informed this works fine on MacOS, which may be down to copy being Cmd+C rather than Ctrl-C there.

Can confirm, works fine on my Mac

Right click copy works.

This would suggest that Ctrl is being captured by something and not handled, since copying still works and Cmd+C works on Mac. I don't believe we have any such code in this part of the UI, so I would wonder if this might be upstream in xterm

[agilgur5]

so I would wonder if this might be upstream in xterm

We're also on an older version of xterm, so probably first thing I would recommend is upgrading it

[Adrien-D]

so I would wonder if this might be upstream in xterm

We're also on an older version of xterm, so probably first thing I would recommend is upgrading it

An existing issue on this topic is still open on xterm project xtermjs/xterm.js#2478 , and seems to be a desired behavior, so no real need of updating the lib.

I implemented a workaround. You can find the related Issue here and PR here