UI: Links from logs stopped being clickable after update

kzzalews commented 5 months ago

Pre-requisites

[X] I have double-checked my configuration
[ ] I have tested with the :latest image tag (i.e. quay.io/argoproj/workflow-controller:latest) and can confirm the issue still exists on :latest. If not, I have explained why, in detail, in my description below.
[X] 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 you expected to happen?

Links from workflows' containers in UI stopped being clickable after switch from Argo Workflows version 3.4.10 to 3.5.7.

Below you can see screenshots from two Argo Workflows versions. These show logs from single step (pod) running in our workflows and these logs could be viewed from Argo Workflows web UI. Please, notice that in old version link is underlined and clickable. In newer version it isn't clickable. It isn't interpreted as such. We've tested that on different web browsers (Safari, Firefox and Chrome).

Anonymized screenshot from version 3.4.10: argo_3 4 10

Anonymized screenshot from version 3.5.7: argo_3 5 7

I suspect that there were some changes in UI modules related to logs rendering (e.g. framework or library update) that lead to such effect.

Version

3.5.7

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.

N/A

Logs from the workflow controller

N/A

Logs from in your workflow's wait container

N/A

agilgur5 commented 5 months ago

I suspect that there were some changes in UI modules related to logs rendering (e.g. framework or library update) that lead to such effect.

Correct, specifically an update of argo-ui in #11585 almost a year ago, which was one of my very first UI contributions. It did also get backported to 3.4.17 in #12998. More specifically, this line upgraded xterm from 2.4.0 to ^4.19.0, which is used as a log viewer. Even more specifically, https://github.com/argoproj/argo-ui/issues/180 followed by https://github.com/argoproj/argo-ui/pull/183.

Please, notice that in old version link is underlined and clickable. In newer version it isn't clickable. It isn't interpreted as such.

I'm not sure that this was ever an intentional feature in Argo; it seems like you were making use of undocumented behavior. As xterm is a terminal UI, it supports some features that some terminals can have, like clickable links.

2.4.0 was quite outdated per https://github.com/argoproj/argo-ui/issues/180, so we would not revert back to it. But perhaps there is an option in the current version to re-enable this behavior.

That being said, xterm is quite large (see #12059) and has many unnecessary features for Argo Workflows, which only uses it as a log viewer, so we may replace it with something (much) smaller, which may very well not have such functionality as making links clickable. I wouldn't guarantee that undocumented behavior would continue working.

tooptoop4 commented 5 months ago

https://github.com/xtermjs/xterm.js/tree/master/addons/addon-web-links has notes on how to re-add

agilgur5 commented 5 months ago

Thanks for the link @tooptoop4. It's roughly ~300 LoC of TS (which would be even smaller when compiled), so pretty small, so I think we can re-enable that for the time being (until xterm is replaced).

Would either you or @kzzalews like to add this upstream to argo-ui? Either that or expose the Terminal instance in argo-ui so that addons can be added downstream here -- this is easier said than done though. Another option would be to have argo-ui take addons as a prop of a list of addon instances (which may require some small optimizations to ensure they're re-used/cached between renders).

kzzalews commented 5 months ago

Thanks @agilgur5 for initial analysis of the issue! Regarding fixing it by myself - unfortunately my lack of skills in this area is a limiting factor :/

argoproj / argo-workflows