Public bug reported:
[ Impact ]
* When a user connects from a local `far2l` instance to a remote one
over SSH in TTY|F mode, any action that triggers the "Clipboard access"
dialog (such as copying or pasting) causes the local `far2l` client to
hang indefinitely. This makes a key feature of remote work unusable and
forces the user to kill the local `far2l` process to recover. This is a
regression introduced in a previous update (commit d1fed9a).
* The fix addresses the root cause of the hang, which was an infinite
loop in the console repaint logic (`SetConsoleRepaintsDefer` /
`ConsoleOutput::RepaintsDeferFinish`). When the clipboard dialog was
supposed to appear over the nested TTY|F session, the repaint mechanism
would get stuck. The uploaded patch corrects this logic, ensuring the
dialog is drawn correctly without entering a loop, thus resolving the
application hang.
[ Test Plan ]
* Objective: To verify that the local `far2l` client no longer hangs
when accessing the clipboard in a remote TTY|F session.
* Setup:
1. You will need two systems (physical or virtual) with `far2l` installed
and SSH access configured between them. Let's call them `local-host` and
`remote-host`.
2. Ensure you can SSH from `local-host` to `remote-host`.
* Steps to reproduce the bug (with the old package):
1. On `local-host`, start `far2l` normally.
2. Within the local `far2l`, connect to the remote host via SSH (e.g.,
using the NetBox plugin or by running `ssh user@remote-host` from the command
line) and run far2l --tty. You should now see the remote `far2l` interface
running inside your local `far2l` window.
3. In the remote session, attempt a clipboard operation.
4. BUG: The local `far2l` instance will freeze. The "Clipboard access"
dialog will not appear, and the application will become unresponsive.
* Steps to verify the fix (with the new package):
1. Follow steps 1-4 from the reproduction plan above.
2. VERIFICATION: The "Clipboard access" dialog should appear correctly on
the local `far2l` instance. The application will not hang. The user can
interact with the dialog (e.g., press OK or Cancel), and both the local and
remote `far2l` sessions will remain fully functional.
[ Where problems could occur ]
* The fix modifies the core console repaint and dialog handling logic.
A regression here could have several visual or functional side effects.
* Rendering Artifacts: The change could inadvertently cause other
dialogs (not just the clipboard access one) to render incorrectly. This
could manifest as missing dialogs, visual corruption, or "ghost" images
from the host session appearing where they shouldn't. Btw, the updated
app was tested in the PPA by enthusiasts, including various dialog and
screen update checks, and no problems were found.
[ Other Info ]
* Original upstream bug report: `https://github.com/elfmz/far2l/issues/2634`
* This bug is a regression introduced by upstream commit `d1fed9a`, which
makes fixing it in a stable release a high priority.
** Affects: far2l (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
[ Impact ]
* When a user connects from a local `far2l` instance to a remote one
over SSH in TTY|F mode, any action that triggers the "Clipboard access"
dialog (such as copying or pasting) causes the local `far2l` client to
hang indefinitely. This makes a key feature of remote work unusable and
forces the user to kill the local `far2l` process to recover. This is a
regression introduced in a previous update (commit d1fed9a).
* The fix addresses the root cause of the hang, which was an infinite
loop in the console repaint logic (`SetConsoleRepaintsDefer` /
`ConsoleOutput::RepaintsDeferFinish`). When the clipboard dialog was
supposed to appear over the nested TTY|F session, the repaint mechanism
would get stuck. The uploaded patch corrects this logic, ensuring the
dialog is drawn correctly without entering a loop, thus resolving the
application hang.
[ Test Plan ]
- * **Objective:** To verify that the local `far2l` client no longer
- hangs when accessing the clipboard in a remote TTY|F session.
+ * Objective: To verify that the local `far2l` client no longer hangs
+ when accessing the clipboard in a remote TTY|F session.
- * **Setup:**
+ * Setup:
1. You will need two systems (physical or virtual) with `far2l`
installed and SSH access configured between them. Let's call them `local-host`
and `remote-host`.
2. Ensure you can SSH from `local-host` to `remote-host`.
- * **Steps to reproduce the bug (with the old package):**
+ * Steps to reproduce the bug (with the old package):
1. On `local-host`, start `far2l` normally.
2. Within the local `far2l`, connect to the remote host via SSH (e.g.,
using the NetBox plugin or by running `ssh user@remote-host` from the command
line) and run far2l --tty. You should now see the remote `far2l` interface
running inside your local `far2l` window.
3. In the remote session, attempt a clipboard operation.
- 4. **BUG:** The local `far2l` instance will freeze. The "Clipboard
access" dialog will not appear, and the application will become unresponsive.
+ 4. BUG: The local `far2l` instance will freeze. The "Clipboard access"
dialog will not appear, and the application will become unresponsive.
- * **Steps to verify the fix (with the new package):**
+ * Steps to verify the fix (with the new package):
1. Follow steps 1-4 from the reproduction plan above.
- 2. **VERIFICATION:** The "Clipboard access" dialog should appear
correctly on the local `far2l` instance. The application will not hang. The
user can interact with the dialog (e.g., press OK or Cancel), and both the
local and remote `far2l` sessions will remain fully functional.
+ 2. VERIFICATION: The "Clipboard access" dialog should appear correctly
on the local `far2l` instance. The application will not hang. The user can
interact with the dialog (e.g., press OK or Cancel), and both the local and
remote `far2l` sessions will remain fully functional.
[ Where problems could occur ]
* The fix modifies the core console repaint and dialog handling logic.
A regression here could have several visual or functional side effects.
- * **Rendering Artifacts:** The change could inadvertently cause other
+ * Rendering Artifacts: The change could inadvertently cause other
dialogs (not just the clipboard access one) to render incorrectly. This
could manifest as missing dialogs, visual corruption, or "ghost" images
from the host session appearing where they shouldn't. Btw, the updated
app was tested in the PPA by enthusiasts, including various dialog and
screen update checks, and no problems were found.
[ Other Info ]
* Original upstream bug report: `https://github.com/elfmz/far2l/issues/2634`
* This bug is a regression introduced by upstream commit `d1fed9a`, which
makes fixing it in a stable release a high priority.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2114513
Title:
Clipboard dialog freeze in nested far2l (TTY|F) session over SSH
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/far2l/+bug/2114513/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
