[GH-ISSUE #91] [BUG] Incorrect Earlier Data Copied to Clipboard #215

New issue

Closed

opened 2026-03-14 20:35:13 +03:00 by kerem · 1 comment

kerem commented

2026-03-14 20:35:13 +03:00

Owner

Originally created by @NeilCresswell on GitHub (May 25, 2025).
Original GitHub issue: https://github.com/Archeb/opentrace/issues/91

Describe the bug 描述你遇到的BUG
After running a traceroute, the first time data is copied to the clipboard via the right click of a mouse on a traceroute table row seems to be correct. However, all future attempts to copy different data from a different hop are all incorrect. No matter what hop I then select, or if I then choose between copying an IP, location, or host name, I still get the original data I first requested copied to the clipboard instead.

To Reproduce 复现方法
Run a traceroute in the app.
Right click on one of the hops and "Copy Hostname".
The correct host name now appears in the clipboard.
Right click on a different hop and select "Copy Hostname".
Incorrectly the first selected hop's host name is copied to the clipboard instead.
Right click on a different hop and select "Copy IP".
Incorrectly the first selected hop's host name is copied to the clipboard instead.
Right click on a different hop and select "Copy Geolocation".
Incorrectly the first selected hop's host name is copied to the clipboard instead.

Screenshots (If applicable) 截图（如果有）
N/A

Environment 使用环境
OS: Fedora Linux Workstation v41 (64 bit) with Gnome 47.6 desktop
OpenTrace Version: v1.4.4.0 installed through Flathub (dl.flathub.org)

Additional context 补充说明
For the incorrect situations I additionally tested by copying other text to the clipboard between each of the OpenTrace copy tests, and can confirm data is copied to the clipboard by OpenTrace every time. Unfortunately it seems OpenTrace is not just providing the results of the original request to copy to clipboard every time you make a new request.

Originally created by @NeilCresswell on GitHub (May 25, 2025). Original GitHub issue: https://github.com/Archeb/opentrace/issues/91 **Describe the bug 描述你遇到的BUG** After running a traceroute, the first time data is copied to the clipboard via the right click of a mouse on a traceroute table row seems to be correct. However, all future attempts to copy different data from a different hop are all incorrect. No matter what hop I then select, or if I then choose between copying an IP, location, or host name, I still get the original data I first requested copied to the clipboard instead. **To Reproduce 复现方法** Run a traceroute in the app. Right click on one of the hops and "Copy Hostname". The correct host name now appears in the clipboard. Right click on a different hop and select "Copy Hostname". Incorrectly the first selected hop's host name is copied to the clipboard instead. Right click on a different hop and select "Copy IP". Incorrectly the first selected hop's host name is copied to the clipboard instead. Right click on a different hop and select "Copy Geolocation". Incorrectly the first selected hop's host name is copied to the clipboard instead. **Screenshots (If applicable) 截图（如果有）** N/A **Environment 使用环境** OS: Fedora Linux Workstation v41 (64 bit) with Gnome 47.6 desktop OpenTrace Version: v1.4.4.0 installed through Flathub (dl.flathub.org) **Additional context 补充说明** For the incorrect situations I additionally tested by copying other text to the clipboard between each of the OpenTrace copy tests, and can confirm data is copied to the clipboard by OpenTrace every time. Unfortunately it seems OpenTrace is not just providing the results of the original request to copy to clipboard every time you make a new request.

kerem

2026-03-14 20:35:13 +03:00

closed this issue
added the
bug
label

kerem commented

2026-03-14 20:35:29 +03:00

Author

Owner

@fakeboboliu commented on GitHub (May 25, 2025):

Thanks for your report, github.com/Archeb/opentrace@7ee4120b79 should fix it.

The nightly build can be get here.

@fakeboboliu commented on GitHub (May 25, 2025): Thanks for your report, https://github.com/Archeb/opentrace/commit/7ee4120b790d6b8855a0b93313aa258217f9565d should fix it. The nightly build can be get [here](https://github.com/Archeb/opentrace/actions/runs/15236851388).