#518 closed defect (fixed)
Opening links in background tab in Chrome causes the window to become unsnapped in Windows 7
Reported by: | J. Max Mena | Owned by: | J. Max Mena |
---|---|---|---|
Priority: | minor | Milestone: | 0.12 |
Component: | client | Version: | |
Keywords: | win32 window snap placement | Cc: |
Description
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.
Attachments (2)
Change History (11)
comment:1 Changed 7 years ago by
Keywords: | win32 window snap placement added; Window Snap removed |
---|---|
Milestone: | → 0.12 |
Owner: | changed from Antoine Martin to J. Max Mena |
comment:2 Changed 7 years ago by
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.
Changed 7 years ago by
Attachment: | xpra debugging all.txt added |
---|
The -d all output, trimmed down to all relevant times
comment:3 Changed 7 years ago by
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.
Changed 7 years ago by
Attachment: | xpra debugging window.txt added |
---|
output of -d window, same test as with -d all : Connect, snap window to the right, open link in new tab, window unsnaps
comment:4 Changed 7 years ago by
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)
comment:5 Changed 7 years ago by
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.
comment:6 Changed 7 years ago by
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, andcontrol-C
it just after.
comment:7 Changed 7 years ago by
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.
comment:8 Changed 7 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Retested with r5531 Windows client. Problem is resolved. Closing
comment:9 Changed 3 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/518
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.