Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UI: Links from logs stopped being clickable after update #13148

Open
2 of 4 tasks
kzzalews opened this issue Jun 6, 2024 · 4 comments
Open
2 of 4 tasks

UI: Links from logs stopped being clickable after update #13148

kzzalews opened this issue Jun 6, 2024 · 4 comments
Labels
area/ui area/upstream This is an issue with an upstream dependency, not Argo itself P3 Low priority solution/suggested A solution to the bug has been suggested. Someone needs to implement it. type/bug type/dependencies PRs and issues specific to updating dependencies type/regression Regression from previous behavior (a specific type of bug)

Comments

@kzzalews
Copy link

kzzalews commented Jun 6, 2024

Pre-requisites

  • 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.
  • 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
@kzzalews kzzalews added type/bug type/regression Regression from previous behavior (a specific type of bug) labels Jun 6, 2024
@agilgur5 agilgur5 added type/dependencies PRs and issues specific to updating dependencies area/ui area/upstream This is an issue with an upstream dependency, not Argo itself labels Jun 6, 2024
@agilgur5
Copy link
Member

agilgur5 commented Jun 6, 2024

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, argoproj/argo-ui#180 followed by argoproj/argo-ui#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 argoproj/argo-ui#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.

@agilgur5 agilgur5 added the P3 Low priority label Jun 6, 2024
@tooptoop4
Copy link
Contributor

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

@agilgur5
Copy link
Member

agilgur5 commented Jun 8, 2024

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).

@agilgur5 agilgur5 added the solution/suggested A solution to the bug has been suggested. Someone needs to implement it. label Jun 8, 2024
@agilgur5 agilgur5 changed the title Links from workflows' containers in UI stopped being clickable after update UI: Links from logs stopped being clickable after update Jun 8, 2024
@kzzalews
Copy link
Author

kzzalews commented Jun 21, 2024

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 :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/ui area/upstream This is an issue with an upstream dependency, not Argo itself P3 Low priority solution/suggested A solution to the bug has been suggested. Someone needs to implement it. type/bug type/dependencies PRs and issues specific to updating dependencies type/regression Regression from previous behavior (a specific type of bug)
Projects
None yet
Development

No branches or pull requests

3 participants