Bug 8468 - Copy links when clicked in tl-setup and installer
Summary: Copy links when clicked in tl-setup and installer
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Server Installer (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.18.0
Assignee: Samuel Mannehed
URL:
Keywords: relnotes, tobfa_tester
Depends on:
Blocks:
 
Reported: 2024-11-29 15:59 CET by Samuel Mannehed
Modified: 2024-12-04 09:14 CET (History)
1 user (show)

See Also:
Acceptance Criteria:
MUST: - When clicking links in tl-setup and the installer, the link URL should be copied to the clipboard. SHOULD: - When running a graphical root session, links should open like before. - Links should show link-texts instead of urls when suitable. - Future developers should not have to actively make links clickable. COULD: - Additional links could be added to other pages in tl-setup.


Attachments

Description Samuel Mannehed cendio 2024-11-29 15:59:31 CET
As described in bug 7704, clicking the links in tl-setup/installer doesn't open a browser window. If tl-setup was started from a terminal, you see this error:
> Running Firefox as root in a regular user's session is not supported.($XDG_RUNTIME_DIR is /run/user/<uid> which is owned by <username>.)

While trying to resolve bug 7704, placing the link URL in the clipboard was used as a fallback. The solution explored wasn't robust enough, so we decided to only keep the fallback and break it out to a new bug -> this one.
Comment 3 Samuel Mannehed cendio 2024-11-29 17:02:51 CET
Tested on RHEL 9 in a Wayland session.

> MUST:
> - When clicking links in tl-setup and the installer, the link URL should be copied to the clipboard.
Yes, it is.
> SHOULD:
> - Links should show link-texts instead of urls when suitable.
Some of them do at least.
> - Future developers should not have to actively make links clickable.
By using a tlgtk.Label class, we get this handler for all labels.
> COULD:
> - Additional links could be added to other pages in tl-setup.
More work could be done here, but we added a link to the sudo-page in tl-setup.
Comment 4 Samuel Mannehed cendio 2024-11-29 17:10:14 CET
> SHOULD:
> - When running a graphical root session, links should open like before.
Yes, the old behavior is kept. If your browser supports running as root, clicking a tl-setup link will open it in the browser. Note that google-chrome does not support running as root, Firefox does.
Comment 5 Tobias cendio 2024-12-03 12:57:35 CET
Tested this using servers 4.17.0 and build #385 on RHEL8, RHEL9, and Ubuntu22.04 (Wayland sessions).

I cannot seem to reproduce comment #4, as I'm only getting a copy to clipboard using build #3852, while I'm getting a browser using 4.17.0; running as the root user.
Comment 6 Tobias cendio 2024-12-03 14:16:00 CET
Regarding comment #5, the mistake was not running a graphical root session, as in logging in as root -- not simply running things as the root user in an otherwise unprivileged user session.

Using this procedure, browsers are indeed spawned when clicking links in the GUI installers.
Comment 7 Tobias cendio 2024-12-03 16:51:03 CET
Tested using server build #3852 in RHEL8, RHEL9, and Ubuntu22.04.

GUI mode
---------------------
Tested clicking the links and they are indeed copied to the clipboard as indented. Running a root graphical session results in an opened browser. For some reason, I observed this same effect in RHEL8 and RHEL9 when running the installers as the root user – in a normal unprivileged graphical session. However, could not reproduce it in Ubuntu22.04. 

Had a look at the relevant code bits, and they look perfectly fine. A supplementary tlgtk.Label class has been added in commit r41404 – and subsequently reduced quite a bit in commit r41436 – which renders future additions less time-consuming.

It is a bit inconsistent in tl-setup what pages exhibit links to some form of support, whether it is the homepage or the TAG; a new bug will be listed on this topic.

Wherever links are present, links to the TAG are consistently abstracted behind a link text, while links to some other page on the homepage are written as the complete url. I find this to be fine, as perhaps one would like to explicitly know where the link is heading on the homepage. Moreover, links to some specific TAG page are generally quite long and less pleasing to the eye.

One thing to note is that the link texts on the ”External connections” and ”sudo” pages in tl-setup refers to the documentation with different labels. Perhaps these should be the same to avoid any confusion.
Comment 8 Tobias cendio 2024-12-03 17:00:43 CET
Regarding inconsistent support links in tl-setup mentioned in comment #7, bug 8471 was created.
Comment 10 Tobias cendio 2024-12-04 08:53:39 CET
Continuing testing from comment #7:

Tested the installers in text mode using server build #3852 on RHEL9 and Ubuntu22.04.

In tl-setup text mode, the same pages as in GUI mode exhibit external links to supporting information. In this text mode case, though, all links in question have been confirmed to be complete URLs, as is intended. These links stretch beyond the normal page limit, but this is of minor concern.
Comment 11 Tobias cendio 2024-12-04 08:56:57 CET
Acceptance criteria

> MUST:
> When clicking links in tl-setup and the installer, the link URL should be copied to the clipboard.
✅ Confirmed. A small dialog window appears, notifying the user of this.

> SHOULD:
> When running a graphical root session, links should open like before.
✅ As long as the browser supports it.
> Links should show link-texts instead of urls when suitable.
✅ Link texts are currently used for TAG references, while links to proper pages on the homepage are complete URLs.
> Future developers should not have to actively make links clickable.
✅ Check. Steps have been taken in the code to streamline this process.

> COULD:
> Additional links could be added to other pages in tl-setup.
❌ This point warrants additional work – a separate bug has been made for this (bug 8471).
Comment 12 Tobias cendio 2024-12-04 09:14:05 CET
Testing of this bug should be complete by now. Essentially all acceptance criteria are fulfilled, in particular the important ones, leaving one lesser point for the future.

Closing.

Note You need to log in before you can comment on or make changes to this bug.