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
*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
Can you still type into the terminal when that happens? Can you collect xpra info? How do I reproduce this bug reliably?
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.
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)
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.
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.
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
)
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)
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
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
.
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.
$ 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
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)
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
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.
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.
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.
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.
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)
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
The server seems "stuck" in that situation, although sometimes some things seem responsive sometimes:
It's a very weird bug.
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.
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)
The issue caused by Sublime Merge seems to have been solved by upstream update.
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
?
I was about to, but I wanted to check it with you.
I think the rest can be tackled in #2778.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2604