Xpra: Ticket #2604: gnome-terminal cannot click-highlight

Something has happened to one of my active sessions, and I cannot click-hold+drag to highlight text. Starting a new one works

First exhibited shortly after I connected with r25314

                                        Xpra top 3.0.6-r25174
Xpra GTK3 X11 server 64-bit
xpra top - 21:34:47 up 8 days, 0:11:08,  0 users, load average: 1.24, 2.10, 2.30
8 threads
cursor at 595x676
1 windows
 ┌──────────────────────────────────────────────────────────────────────────────────────────────┐
 │Terminal                                                                                      │
 │1596x832 at 0,23 - minimum-size=(298, 79), gravity=1, increment=(9, 17), base-size=(12, 50)   │
 │maximized                                                                                     │
 │NORMAL                                                                                        │
 └──────────────────────────────────────────────────────────────────────────────────────────────┘

Window "appears to be normal" otherwise



Thu, 20 Feb 2020 19:39:31 GMT - stdedos:

*pointer is a mouse, not "that text-select I-thing" anymore.


Actually, scratch that: See also #2606 I don't know if starting extraneous applications via the terminal affects it, and it has happened on my new session too. It voids all mouse input.


The other common thing that #2606 case and this have, is that "Network Performance Issues" has been triggered. Note that, however, both the Shadow session *and* the gnome-terminal are open (on both occurrences), so I don't know if indeed the gnome-terminal triggered it, or the Shadow server. I remember that usually the window title of the "information box" is Compiz (i.e. I assume Shadow server), but I cannot say I have been paying close attention to that since it only comes on the taskbar - I am more likely to look at message box's own window


Fri, 21 Feb 2020 09:09:01 GMT - Antoine Martin: owner changed

Can you still type into the terminal when that happens? Can you collect xpra info? How do I reproduce this bug reliably?


Fri, 21 Feb 2020 10:20:50 GMT - stdedos:

Replying to Antoine Martin:

Can you still type into the terminal when that happens?

Yes, keyboard shortcuts work fine

Can you collect xpra info?

Attached

How do I reproduce this bug reliably?

¯\_(ツ)_/¯ No idea

(I am not sure if the X applications are necessary)

Note that I can use the mouse e.g. to activate windows, or use the OS Minimize / Maximize / Close buttons.


Fri, 21 Feb 2020 10:21:16 GMT - stdedos: attachment set


Tue, 03 Mar 2020 18:50:06 GMT - stdedos:

Mouse wheel it goes up or down the opened tabs, instead of scrolling the terminal (without transitioning from last to first tab and vice-versa, like the Shift+PgDown/PgUp shortcut does).

If no further diagnostics are usefull, I'll shutdown the server itself (since it's increasingly difficult to interact with it)


Wed, 04 Mar 2020 05:24:25 GMT - Antoine Martin:

Mouse wheel it goes up or down the opened tabs, instead of scrolling the terminal (without transitioning from last to first tab and vice-versa, like the Shift+PgDown / PgUp shortcut does).

Probably because one of your modifier keys is stuck in pressed state. You can try pressing + unpressing them all until you find the stuck one. Re-connecting normally fixes this.


Wed, 04 Mar 2020 15:31:41 GMT - stdedos:

I have re-connected in-between these 12 days :-D. Is it possible that the server "persists" stuck modifier keys? Can I query it?

Sadly, the server blew up hard yesterday; I'll have to wait until I replicate the bug.


Thu, 05 Mar 2020 05:08:52 GMT - Antoine Martin:

I have re-connected in-between these 12 days :-D. Is it possible that the server "persists" stuck modifier keys? Can I query it?

All X11 servers (seamless, desktop and shadow) will unpress all the keys that they had pressed (calling clear_keys_pressed during client connection cleanup). They will also call unpress_all_keys, which calls low-level X11 functions to ensure we unpress any keycode currently pressed, even if xpra was not the one to press it.

The keys currently pressed are always visible using xpra info | grep keys_pressed. (but that's only xpra's view, the server state may vary - which is why we also use unpress_all_keys)


Thu, 05 Mar 2020 21:04:56 GMT - stdedos:

I've found a way to replicate it:

On a new gnome-terminal session, I've started LibreOffice to verify #2534. After trying hard to verify it, sometime when I started re-using the gnome-terminal it happened.

xpra info | grep keys_pressed is empty. I assume that "server's state" is not different (can I call unpress_all_keys by myself?)

I "resolved" it by switching back to LibreOffice and working with it a little bit more. The condition in LibreOffice was the same (mouse clicks did not work), I de-focused it and re-focused it, and LibreOffice started working.

After that, gnome-terminal also worked normally (click-mark etc)


Thu, 19 Mar 2020 10:31:36 GMT - stdedos:

Another random occurence (but the server is and has been running a lot of applications, so, I don't know what could've caused it).

xpra info | grep keys_pressed is empty. I assume that "server's state" is not different (can I call unpress_all_keys by myself?).

modal-windows is disabled, reconnecting does not help.

Can I seamlessly move applications to a different display? :-D


Fri, 20 Mar 2020 08:17:41 GMT - Antoine Martin:

As of r25700 + r25701, xpra info will now also show what keys are pressed according to the X11 server, ie here with Shift + Control + c:

keyboard.state.keycodes-down.37=('Control_L', 'Control_L', 'Control_L', 'Control_L')
keyboard.state.keycodes-down.50=('Shift_L', 'Shift_L', 'Shift_L', 'Shift_L')
keyboard.state.keycodes-down.54=('c', 'c', 'c', 'c')

Another thing that may play a role is keyboard-sync.


Fri, 20 Mar 2020 12:51:58 GMT - stdedos:

I haven't had time to check the new suggestions for now (also I cannot update because apt-get is not picking up the new version, #2663), but it seems that Sublime Merge is doing that "blocking of clicking on stuff" on the attached session.

If Sublime Merge can handle the xpra repository, just try to make one commit via the GUI. Stage files, select text etc, and it should trigger it in a couple of minutes or so.


Mon, 23 Mar 2020 12:50:28 GMT - stdedos:

$ xpra info :200 | grep keyboard.state
keyboard.state.keys_pressed=()

Also, if that helps: X11-cursor rendered is this the same as xkill "X" cursor


Mon, 23 Mar 2020 12:55:24 GMT - Antoine Martin:

As per comment:10, try:

$ xpra info :200 | egrep "keyboard.state|keycodes-down"

To see both xpra's keys pressed and the ones the X11 server knows about. (r25701 or later)


Mon, 23 Mar 2020 13:10:04 GMT - stdedos:

Same difference:

u@h:~$ xpra info :200 | grep -E 'keyboard.state|keycodes-down'
keyboard.state.keys_pressed=()
u@h:~$ xpra --version
xpra v3.0.8-r25722

Mon, 23 Mar 2020 13:12:50 GMT - Antoine Martin:

Same difference: (..)

Then there are no keys pressed, and it's not because of the keyboard state.

Please attach xpra info of when the problem occurs, maybe it's a stacking or focus problem.


Mon, 23 Mar 2020 15:50:32 GMT - stdedos: attachment set


Mon, 23 Mar 2020 17:00:17 GMT - Antoine Martin:

From this xpra info output:

windows.1.class-instance=('gnome-terminal-server', 'Gnome-terminal')
windows.1.client-geometry=(0, 23, 1600, 837)
windows.1.focused=0
windows.1.geometry=(0, 23, 1596, 832)
windows.1.state=('_NET_WM_STATE_FOCUSED', '_NET_WM_STATE_MAXIMIZED_VERT', '_NET_WM_STATE_MAXIMIZED_HORZ')
windows.1.window-type=('NORMAL',)
windows.2.class-instance=('prog-1', 'prog-1')
windows.2.client-geometry=(0, 23, 1600, 837)
windows.2.focused=0
windows.2.geometry=(0, 23, 1600, 837)
windows.2.state=('_NET_WM_STATE_MAXIMIZED_VERT', '_NET_WM_STATE_MAXIMIZED_HORZ')
windows.3.class-instance=('prog-1', 'prog-1')
windows.3.client-geometry=(0, 23, 1600, 837)
windows.3.focused=0
windows.3.geometry=(0, 23, 1600, 837)
windows.3.state=('_NET_WM_STATE_MAXIMIZED_VERT', '_NET_WM_STATE_MAXIMIZED_HORZ')

None of the windows are focused. And I don't see anything unusual here. Maybe you can attach the file created by calling xpra screenshot? I really don't know what else to try since I can't reproduce this.


Mon, 23 Mar 2020 17:27:47 GMT - stdedos:

Replying to Antoine Martin:

None of the windows are focused.

Are you sure? What does _NET_WM_STATE_FOCUSED mean then? 😕

Should at least one window be always focused?

When the issue was replicated, I left the window as-is and switched to a different xpra instance (with click-select capabilities) to collect the diagnostics. Should at least one window be always focused server-side regardless if any window of this xpra server instance is focused or not?

And I don't see anything unusual here. Maybe you can attach the file created by calling xpra screenshot?

I am really not sure what are you expecting to see here 😕

I really don't know what else to try since I can't reproduce this.


Mon, 23 Mar 2020 17:28:01 GMT - stdedos: attachment set


Mon, 23 Mar 2020 17:41:54 GMT - Antoine Martin:

Are you sure? What does _NET_WM_STATE_FOCUSED mean then? 😕

That the window state can show the window as being focused. It's not the same as the X11 focus...

Should at least one window be always focused?

No. If you raise a window not managed by xpra (say notepad), then all the xpra forwarded windows will lose the focus, which will go to the root window.

I am really not sure what are you expecting to see here 😕

Not sure really. The terminal that is on top of the stack, despite its "focused" state flag.


Mon, 23 Mar 2020 17:48:49 GMT - stdedos:

Replying to Antoine Martin:

I am really not sure what are you expecting to see here 😕

Not sure really. The terminal that is on top of the stack, despite its "focused" state flag.

I may have switched to the gnome-terminal to write xpra-info, and may forgot to switch back. *may: because each seamless xpra server starts with a gnome-terminal, it's hard to pick the correct one every time. I know I have done this a couple of times i.e. raise :200's gnome-terminal, only to switch to :20 to do the same thing all over again.

However, the session during xpra-screenshot was unattached. I think I have Ctrl+C'ed the client this time (and not just shut the lid)


Tue, 24 Mar 2020 04:26:16 GMT - Antoine Martin:

I may have switched to the gnome-terminal to write xpra-info, and may forgot to switch back.

FYI: to collect xpra info for a specific situation, I usually run it in the background with a delay so I have time to switch back to the setup I want to capture before it runs:

sleep 5;xpra info > info.txt

Tue, 24 Mar 2020 06:40:51 GMT - stdedos:

The server seems "stuck" in that situation, although sometimes some things seem responsive sometimes:

It's a very weird bug.


Tue, 24 Mar 2020 09:08:15 GMT - stdedos:

After the night has passed, now I can click-highlight on the terminal. ... but not click, or hover&mouse-scroll on top of Sublime Merge.

Artifacts will soon (tm) follow.


Tue, 24 Mar 2020 15:08:20 GMT - stdedos: attachment set


Tue, 24 Mar 2020 15:08:27 GMT - stdedos: attachment set


Fri, 27 Mar 2020 05:52:32 GMT - Antoine Martin: owner, status, milestone changed


Mon, 06 Apr 2020 12:27:22 GMT - stdedos:

I may have found a workaround: Brute-force right-and-left click, until the triggered actions (i.e. right and left click) decide to register and execute (usually a couple of seconds later)


Mon, 13 Jul 2020 08:20:15 GMT - stdedos:

The issue caused by Sublime Merge seems to have been solved by upstream update.


Mon, 13 Jul 2020 08:25:41 GMT - Antoine Martin: owner, status changed

The issue caused by Sublime Merge seems to have been solved by upstream update.

Can we close this ticket or is there still a problem with gnome-terminal?


Mon, 13 Jul 2020 08:26:53 GMT - stdedos: status changed; resolution set

I was about to, but I wanted to check it with you.

I think the rest can be tackled in #2778.


Sat, 23 Jan 2021 05:55:49 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2604