xpra icon
Bug tracker and wiki

Opened 4 months ago

Last modified 3 months ago

#2604 assigned defect

gnome-terminal cannot click-highlight

Reported by: stdedos Owned by: Antoine Martin
Priority: major Milestone: 4.1
Component: client Version: 3.0.x
Keywords: Cc:

Description

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

Attachments (5)

xpra-info-2604.log (183.7 KB) - added by stdedos 4 months ago.
redact-xpra-2604-200.log (344.2 KB) - added by stdedos 3 months ago.
xpra-2604-200.png (47.1 KB) - added by stdedos 3 months ago.
redact-xpra-2604-200-v2.log (391.5 KB) - added by stdedos 3 months ago.
xpra-2604-200-v2.png (110.7 KB) - added by stdedos 3 months ago.

Download all attachments as: .zip

Change History (29)

comment:1 Changed 4 months ago by 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

Last edited 4 months ago by stdedos (previous) (diff)

comment:2 Changed 4 months ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos

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

comment:3 in reply to:  2 Changed 4 months ago by 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

  • Start a session with gnome-terminal
  • Play with 3-4 tabs (one of them has byobu/tmux, the other one some X application from Sublime-Merge, Flatpak-Evolution, Diffmerge)
  • ... wait for it

(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.

Last edited 4 months ago by Antoine Martin (previous) (diff)

Changed 4 months ago by stdedos

Attachment: xpra-info-2604.log added

comment:4 Changed 4 months ago by 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)

Last edited 4 months ago by Antoine Martin (previous) (diff)

comment:5 Changed 4 months ago by 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.

Version 0, edited 4 months ago by Antoine Martin (next)

comment:6 Changed 4 months ago by 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.

comment:7 Changed 4 months ago by 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)

comment:8 in reply to:  7 Changed 4 months ago by 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)

Last edited 4 months ago by stdedos (previous) (diff)

comment:9 Changed 4 months ago by 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

comment:10 Changed 4 months ago by 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.

comment:11 Changed 4 months ago by 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.

Last edited 3 months ago by stdedos (previous) (diff)

comment:12 Changed 3 months ago by 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

comment:13 Changed 3 months ago by 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)

comment:14 Changed 3 months ago by 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

comment:15 Changed 3 months ago by 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.

Changed 3 months ago by stdedos

Attachment: redact-xpra-2604-200.log added

comment:16 Changed 3 months ago by 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.

comment:17 in reply to:  16 Changed 3 months ago by 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.

Changed 3 months ago by stdedos

Attachment: xpra-2604-200.png added

comment:18 Changed 3 months ago by 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.

comment:19 in reply to:  18 Changed 3 months ago by 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)

comment:20 Changed 3 months ago by 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

comment:21 Changed 3 months ago by stdedos

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

  • I can click-select in Sublime Merge, but not in the terminal
  • I cannot scroll up/down, but sometimes I can use scrolling bars with click-drag
  • My clicks feel "inoperational", but I can use them to "switch panes" to Sublime Merge and then use keyboard navigation.

It's a very weird bug.

Last edited 3 months ago by stdedos (previous) (diff)

comment:22 Changed 3 months ago by 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.

Changed 3 months ago by stdedos

Attachment: redact-xpra-2604-200-v2.log added

Changed 3 months ago by stdedos

Attachment: xpra-2604-200-v2.png added

comment:23 Changed 3 months ago by Antoine Martin

Milestone: 4.04.1
Owner: changed from stdedos to Antoine Martin
Status: newassigned

comment:24 Changed 3 months ago by 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)

Note: See TracTickets for help on using tickets.