Fedora Account System
Red Hat Associate
Red Hat Customer
This is a very creative bug. I really wonder, how such things can be introduced accidentially: If a logical line spans several displayed lines in xterm and i double-click a word not in the first of the displayed lines, the selection is effective in the first displayed line nonetheless. When you look at the window-shot in the URL, you see the selection. Unfortunately the mouse-pointer is not visible, but i can tell you, that it was positioned over the /usr/ 5 lines below. It could have been also on the /usr 4 lines below or on the -sandboxReporter, the selection is always in the first displayed line. Reproducible: Always Steps to Reproduce: 1. start xterm 2. let xterm display some stuff that is longer than a line e.g. ps -ewwf 3. double-click on a part of the not-first line of a logical line spanning several displayed lines Actual Results: not the part, the mouse is over, is selected, but something above Expected Results: The part, where the mouse is over, is selected Additional Information: When i click and drag, the selection is correct i.e. not effective in another area. It happens only on double-click. Selecting the entire line with triple-click is also correct.
From the description, that's working as designed (for a very long time). Quoting from the manpage https://invisible-island.net/xterm/manpage/xterm.html#h3-Selection-Functions Multiple-click is determined by the time from button up to button down, so you can change the selection unit in the middle of a selection. Logical words and lines selected by double- or triple- clicking may wrap across more than one screen line if lines were wrapped by xterm itself rather than by the application running in the window. If the key/button bindings specify that an X selection is to be made, xterm will leave the selected text highlighted for as long as it is the selection owner.
If I'm misreading it, the actual version number helps, and of course a screenshot.
I see a screenshot, and will see if I can reproduce the effect.
hmm - the screenshot is consistent with xterm getting mouse events on the first line. But you're saying that the mouse pointer could be on "any" part of the wrapped line. So an explanation in terms of broken mouse coordinates doesn't fit. (If my reading about "any" is incorrect, then this would fit). I don't have a Fedora 44 at the moment, but have rawhide (I thought it would be close enough, since it's patch #410). But checking https://packages.fedoraproject.org/pkgs/xterm/xterm/ it says Fedora 44 has #406. I don't see anything to remind me in the changelog, and I have a #406 (on Debian), which in a quick check doesn't misbehave in this way. I checked my rawhide #410 on its desktop, and Debian #406 on XQuartz. Mouse coordinate problems are more likely in the former, but I generally don't see _those_ since the VM doesn't have hardware acceleration :-)
As an afterthought, it would be possible for some shell program to catch a single mouse click and move it to that position, by using reverse-wraparound followed by left-cursor with a large parameter, and then (using the column from the mouse click) back to the right. That's unlikely (I think) but people using zsh for instance have a lot of odd add-ons. I'll probably install a Fedora 44 "soon" (I have 42, 43 and rawhide, intending to drop 42.
Thank you for explaining the multi-click behaviour of xterm. But frankly i know this. I'm using xterm nearly every day since about 1993, after cmdtool and shelltool on SunOS openlook and iirc termtool on sunview had been retired. Interesting observation: I have an Fedora 42 here and there the effect is not visible locally. When i ssh to a system with Fedora 44 and start an xterm with Display-redirection to the local fedora 42 display (wayland), the effect is there, so it is definitely the xterm on Fedora 44 and nothing im terms of the shell. It does not matter, if a tcsh or bash is running in the xterm. Ok, right, you deserve a version (sorry i was tired after work, what in the IT area is a mere bug-hunting and workarounding today): xterm-406-1.fc44.x86_64 If it was not clear enough: The 2nd section of this post spans nearly 3 lines in the text area in my case. You might resize your browser window to achieve this. Now assume you double-click the last word "xterm" and the word "with" 2 display lines above is selected.
I was using Apollo back then, and only recall xterm from sometime in 1988-1994 as a graphical thing in SR10.4 that didn't behave as nicely as Apollo's "pad" windows. SR10.4 came out in March 1992, so I must be recalling from the last couple of years in that range. I see some mention here of xterm https://web-docs.gsi.de/~kraemer/COLLECTION/www.zepa.net/apollo/Apollo-FAQ.html I installed Fedora 44, and don't see this problem. However, there's an area where I wouldn't see it. I'm using Parallels (on a MacMini), and sense that there's some lack of support for hardware acceleration. (Ditto for VirtualBox). I might see some acceleration bugs with VMWare (assuming that's the root cause). If that's the answer, I suppose it works something like this: as xterm writes long lines which wrap, it does the scrolling by shifting the window up -- which is a graphical operation that some clever person might optimize in some obscure manner. So... the first row of a wrapped line happens to not follow some special case of writing to the end of the line and shifting. If you do a repaint of the screen (control left mouse "Redraw Window"), that odd behavior might just go away because the boundary conditions for the text all are discarded (no shifting, etc).
Interesting. Apollo/Aegis i was using in 1986 at Siemens as an intern and unless my memory is romanticizing it, the terminal window was the most mature one i had to do with. It was never scrambled, history recall was always doing, what i expected, i was never wondering, wtf it is doing now Regarding our xterm issue: i installed xterm-401-2.fc43, then xterm-397-1.fc42 on fc44 and found, that 401 already has the issue. However, 397 is working flawlessly on fc44. I looked through the changelog and there are 2 points, i'd consider candidates for the cause: * adjust reported window-position by the shell window's border with ... (patch #401) * revise a limit-check in selection to fix a regression in patch #398 (Debian #1105738) (patch #398) I'm on vacation now for a week and will experiment when i'm back.
Created attachment 2146711 [details] Patch reverting a change that caused the vertical offset when double-clicking This diff reverts the modification causing the vertical offset during double clicks. However, it introduces a horizontal offset in some cases. My guess is, that this modification was made to fix the horizontal offset, but introduced selecting always in the first part of a wrapped line. So this is not a complete fix of the biased double-click selection. When i find leisure and muse, i'll try to work out a real fix.
thanks. I'm in the middle of a larger change, which hasn't modified this function. So... I'll try to dig into the root cause for this when I'm done.
fwiw, my checkin comment for this says it was to fix a potential overflow/underflow. and reading the diff, it looks as if the comparison against zero is backwards.