Opening links in background tab in Chrome causes the window to become unsnapped in Windows 7

[J. Max Mena]

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.

[Antoine Martin]

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.

[J. Max Mena]

Alright, I managed to trim it down to:

• 1 second before pinning to the right
• 2 seconds after opening new link in new tab (and it unsnaps)

Relevant times are as follows:

• 12:49:20 = time pinned (roughly)
• 12:49:30 = time opened new tab and unsnaps(roughly)

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.

[J. Max Mena]

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

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

[J. Max Mena]

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

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

Questions:

• does this occur if you middle click to open in new tab (may require changing some settings)
• does this also occur with older client and/or server versions (0.11.x) which do not have pointer-grab (see #139) support?
• worth checking with --opengl=off, to verify this isn't GL related (very unlikely but still) and because the log output will be more concise.
• this is strangely reminiscent of #423, has that one regressed? Is this new bug also present in 0.10.x?

---

Notes:

• as of r5475, window event logging includes more details about the window, including its ID, so we can know for sure which window it is, either by looking up the ID in the log, or by using xpra info to match it.
• I see some 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)

[J. Max Mena]

Alrighty I retested with Server version 0.11.1-1, and clients all the way back to r4168.

• This seems very similar to #423, but I tried maximizing and it stays maximized.

In regards to your questions:

• Yes, middle mouse button causes the same issue. However, I have been able to reproduce this in Lazarus browser without opening new tabs. Simply clicking on the tab menu and then closing the tab menu causes the window to become un-snapped. I'll keep playing around with this and see if I can't find more ways to make it unpin. If I find anything reproducible, I'll post another comment.
• Issue is consistent in clients all the way back to r4168.
• Checked with opengl disabled, no change.
• In the 0.10.0 r4168, the issue was the same.

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.

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

• for the client, it may be a good idea to prepare everything: even have the context menu already open using the keyboard, and the "open in new tab" option already selected, then make a note of the client time in the log and just press "enter" to select this option, then stop the logging right there.
• the server is much easier, at least from another machine: just tail -n0 -f thefull.log > trimmed.log the log file, starting before pressing enter, and control-C it just after.

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

[J. Max Mena]

Retested with r5531 Windows client. Problem is resolved. Closing

[migration script]

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