Using the "window snap" function in Windows 7 Windows Key + Arrow Left or Right
and browsing in Chrome sometimes causes the window to revert to it's original shape and location. The most reproducible situation is right clicking on a link and clicking "Open Link in New Tab". I've rechecked all the way back to 0.10 r4168, and it's behaved consistently.
Interestingly, Firefox works just fine.
Can you please post the client full debug log of just when that happens (note the start time, "open link in new tab", note the end time) ?
And also if possible, the same thing for when the window is originally snapped into place. Maybe we need to detect such state (if there is one..) and deal with it somehow.
Alright, I managed to trim it down to:
Relevant times are as follows:
It unsnaps so quickly after hitting new tab, it's hard to write down specific times.
I'll attach the relevant logs in a .txt.
The -d all output, trimmed down to all relevant times
I repeated the test, this time with -d window as an argument; I'll attach the relevant .txt as well. Hopefully this should help as well.
output of -d window, same test as with -d all : Connect, snap window to the right, open link in new tab, window unsnaps
I've trimmed the log with:
egrep -v \ "pointer-position|sound|add_data|mask_to|GLPixmap|AVImage|AVFrame|make_csc|swscale|CSCImage|texture |record_decode_time|after_draw|process_draw" thelogfile
And I believe this is the snap event. A partial key press since this the key combo is intercepted by the client OS, followed by the window placement (the time matches too):
send_key_action(3, <GTKKeyEvent object, contents: \ {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Meta_L', \ 'pressed': True, 'keyval': 65511, 'keycode': 91}>) Got configure event: <gtk.gdk.Event at 09D9E5F0: GDK_CONFIGURE x=808, y=210, width=784, height=862>
Then we get the key release for the intercepted key we never saw pressed ("Right
")...
send_key_action(3, <GTKKeyEvent object, contents: \ {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Right', \ 'pressed': False, 'keyval': 65363, 'keycode': 39}>)
And for the Meta_L
key release (not shown here - identical to key press event above).
Then, not much, until we get a pointer-grab
followed by the creation of a new override-redirect
POPUP_MENU
window (I assume this is where you chose "open in new tab"?)
But no sign of the original window being modified in any way, just some repaints (draw_region
etc).
On the other hand with the attachment/ticket/518/xpra%20debugging%20window.txt log, I do see a configure event on what I believe is your main (snapped) window:
Got configure event: <gtk.gdk.Event at 03CEBC08: GDK_CONFIGURE x=16, y=240, width=784, height=747>
(the menu window I assume is this smaller one: make_new_backing(<class 'xpra.client.gtk2.pixmap_backing.PixmapBacking'>, 243, 187)
)
Questions:
pointer-grab
(see #139) support?
--opengl=off
, to verify this isn't GL related (very unlikely but still) and because the log output will be more concise.
Notes:
xpra info
to match it.
window_state_updated
events (especially in the second log sample which has 3), but none of those contain any flags (the value is zero). It is entirely possible that GTK exposes the snap/unsnap event to us but that it has no suitable flag value for it.
maxmylyn: for future reference: the "full" (-d all
) log file is full of sound stuff, making it hard to see anything. First ascertain if sound is relevant, then if not turn it off, then move on to the next large item you can try to disable and repeat. This really helps to narrow things down a bit.
Whilst I'm on the subject, another tiny nitpick: best to include something from the bug description in the attachments (otherwise we end up with hundreds of files all named "xpra debugging" - for one, "xpra" is probably redundant in most cases)
Alrighty I retested with Server version 0.11.1-1, and clients all the way back to r4168.
In regards to your questions:
As far as nitpicking goes, please nitpick all you want. The better I can present the information to you, the faster things can get done. And I'll be sure to keep the filenames in mind in the future.
Oh well, I can't seem to use those shortcuts as they get intercepted by my window manager before it reaches win7 running inside virtualbox. And since there is no way (that I can find) to either change these shortcuts or trigger them via some other means, I am going to have to rely on you for this one. *If* I have time, I could change my X11 window manager to something more barebones (something that won't intercept the window key).
Please post the -d all
log of both client and server, trimmed to only show the event (cut the log just before triggering it, and just after the unsnap).
tail -n0 -f thefull.log > trimmed.log
the log file, starting before pressing enter, and control-C
it just after.
Running with openbox as a lightweight window manager, I was able to use the "windows" key in virtualbox.
Then it's pretty obvious running with "-d all
" that as soon as you open a new tab, chrome / chromium emits a _NET_ACTIVE_WINDOW
, and we respond to it by forwarding it to the client as a "window raise", which the client translates into a gtk.Window.present call. Windows then decides that presenting the window means that it should undo the "snap mode", for whatever reason.
Unfortunately, for "aero": there is no API, no documentation and there is no reference except the brand name, there is no way for us to know when the window is snapped and when it isn't.
So the best I could come up with is r5523, which skips calling Window.present()
when the window already has top level focus. On win32, I believe it is impossible for the window not to have top level focus when interacting with it, so this should not make any difference there. On Linux, it is possible, but I don't think it matters much - we managed without the "window-raise" feature for years!
Please test and close.
Retested with r5531 Windows client. Problem is resolved. Closing
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/518