Xpra: Ticket #518: Opening links in background tab in Chrome causes the window to become unsnapped in Windows 7

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.

Fri, 14 Feb 2014 02:37:18 GMT - Antoine Martin: keywords, owner changed; milestone set

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.

Fri, 14 Feb 2014 21:04:43 GMT - J. Max Mena:

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.

Fri, 14 Feb 2014 21:05:25 GMT - J. Max Mena: attachment set

The -d all output, trimmed down to all relevant times

Fri, 14 Feb 2014 21:15:15 GMT - J. Max Mena:

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.

Fri, 14 Feb 2014 21:16:09 GMT - J. Max Mena: attachment set

output of -d window, same test as with -d all : Connect, snap window to the right, open link in new tab, window unsnaps

Sat, 15 Feb 2014 07:22:29 GMT - Antoine Martin:

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))



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)

Thu, 20 Feb 2014 20:32:20 GMT - J. Max Mena:

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.

Fri, 21 Feb 2014 03:36:00 GMT - Antoine Martin:

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

Fri, 21 Feb 2014 09:57:53 GMT - Antoine Martin:

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.

Fri, 21 Feb 2014 19:17:34 GMT - J. Max Mena: status changed; resolution set

Retested with r5531 Windows client. Problem is resolved. Closing

Sat, 23 Jan 2021 04:58:09 GMT - migration script:

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