Opened 8 years ago
Last modified 4 years ago
#15863 new defect
Auto-Resize is broken with tiling window managers
Reported by: | amosb | Owned by: | |
---|---|---|---|
Component: | GUI | Version: | VirtualBox 5.1.4 |
Keywords: | Cc: | ||
Guest type: | Windows | Host type: | Linux |
Description
I run Archlinux with i3wm, installed VirtualBox via pacman (virtualbox). A recent update has caused nasty behavior around window sizing for guests: using the "auto-resize" feature is completely broken. The window is now resized to some seemingly arbitrary size, and I cannot override it (it just resizes right back). It also cannot be auto reassigned to a specific workspace.
Attachments (14)
Change History (116)
comment:1 by , 8 years ago
comment:2 by , 8 years ago
Same.
Host: Debian Stretch Version: 5.1.4_Debian r110228. Guest: Windows 7 and Ubuntu 12.04
VM window is some tiny value by default (maybe 50x100?). If auto-resize guest display is turned on, the window immediately reverts to this tiny value when changed. If auto-resize is turned off the window can be resized and the guest display stays at whatever the set value is.
This happens regardless of whether the Oracle VM VirtualBox Extension Pack is installed. The 5.1.4 Guest Additions is installed.
comment:3 by , 8 years ago
Hi, i reported this same issue on the Debian BTS too [0]. As i suppose there:
[...] I wouldn't say the autoresize feature of guest additions is not working though, since resizing the virtual machine window is reflected into 'xrandr' output in the guest. The window would autofit, because resolution is set correctly, it's just like the virtual machine is forced inside that subwindow. In the attached screenshot you can see the virtual system rendered in the left part of the window... the right part is actually the main virtualbox window which is behind it, but it could be the rightmost part of a different window or workspace as well, it just depends on what is focused before switching to the virtual machine window. [...]
You can read more about the system setup and see the attached screenshot at the linked bug URL [0].
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837426
follow-up: 7 comment:5 by , 8 years ago
Will Everett, which versin of the VirtualBox Guest Additions do you have installed in your guest?
comment:6 by , 8 years ago
I have the same issues since updating VB from version 5.0.22-1 to 5.1.6-1. In my case the resize-functionality actually works, but the guestVM is displayed the way it is shown on your picture. This happens even with Linux guestVMs where no xorg is installed, so the guest-additions shouldn't be relevant for this issue. In my opinion the source of the issue is more like an missing “redraw-window” call or something like that in the newer VB versions. My workaround is to restart i3 (checkout your i3-config, there has to be a shortcut definition like this: „bindsym $mod+Shift+Q restart“). This forces i3 to redraw all windows. Unfortunately the restart has to be initiated every time the guest-VM changes the resolution (for example at and after the boot-process or after moving the guest-Window to a workspace with different resolution).
follow-up: 8 comment:7 by , 8 years ago
Replying to frank:
Will Everett, which versin of the VirtualBox Guest Additions do you have installed in your guest?
Currently running:
- Virtualbox: 5.1.6_Debian r110634
- Guest Additions: VBoxGuestAdditions_5.1.6.iso
- vbox-extension pack: Oracle_VM_VirtualBox_Extension_Pack-5.1.6-110634.vbox-extpack
The upgrade to 5.1.6 didn't fix anything. Removing the extension pack doesn't change anything.
follow-up: 9 comment:8 by , 8 years ago
Replying to Will Everett:
Replying to frank:
Will Everett, which versin of the VirtualBox Guest Additions do you have installed in your guest?
Currently running:
- Virtualbox: 5.1.6_Debian r110634
- Guest Additions: VBoxGuestAdditions_5.1.6.iso
- vbox-extension pack: Oracle_VM_VirtualBox_Extension_Pack-5.1.6-110634.vbox-extpack
The upgrade to 5.1.6 didn't fix anything. Removing the extension pack doesn't change anything.
I also think it's worth pointing out that this happens with both a Windows 7 guest and a Kubuntu 12.04 guest.
comment:9 by , 8 years ago
I didn't say, that the upgrade to 5.1.6-1 solved the problem for me, rather it introduced it! Have you tried the workaround? If this solves your problem as well, maybe it would help to find the source of this issue. Sometimes I have to restart i3 up to 4 times until the window is displayed right. This is annoying and I really hope that this issue will be fixed in the upcoming version.
follow-up: 11 comment:10 by , 8 years ago
Is my understanding correct that everyone experiencing this issue is using i3 (which I'm afraid I don't think anyone on our team knows) on their host? Interaction between applications and window managers tends to be a rather complex matter. Has anyone tried reporting this to the i3 developers? Either on their bug tracker, or just on a mailing list or on IRC? It might help to get it resolved if one of the i3 developers can reproduce the issue and join this ticket to help sort it out. I suspect this is something they will be able to analyse much faster than we could.
comment:11 by , 8 years ago
I am getting exactly the same issue using the wmii window manager. Similarly to i3, it is a tiling window manager. Thus I doubt it is a i3-specific issue.
comment:12 by , 8 years ago
I still suspect that it could be solved much faster with the help of the i3 developers.
comment:13 by , 8 years ago
Replying to michael:
Is my understanding correct that everyone experiencing this issue is using i3 (which I'm afraid I don't think anyone on our team knows) on their host? Interaction between applications and window managers tends to be a rather complex matter. Has anyone tried reporting this to the i3 developers? Either on their bug tracker, or just on a mailing list or on IRC? It might help to get it resolved if one of the i3 developers can reproduce the issue and join this ticket to help sort it out. I suspect this is something they will be able to analyse much faster than we could.
comment:14 by , 8 years ago
I found another strange error, which is causing vm-crash and described it here: https://www.virtualbox.org/ticket/16059 It could be related to this issue and maybe you guys using tiling wms should take a note of that.
I have now downgraded vbox to the old version and everything works just fine. Furthermore I picked the log-lines which are outputed while resizing the window in the new(buggy) and old(stable) version. I added few comments to specify the state of my guestvm and the performed actions.
by , 8 years ago
Attachment: | vbox_window_resize.zip added |
---|
guestvm window-resize logs of stable and buggy versions
comment:15 by , 8 years ago
Hi guys, I'm one of the developers over at i3. Thanks for involving us here :-)
I've given this a quick look, but unfortunately cannot reliably reproduce it yet (but can reproduce it.) Actually I also know some coworkers of mine affected by it. Anyway, I've looked at our i3 log files and some X information and noticed a few things. I'd love to xtrace virtualbox, but when attempting so, it just doesn't even start up :-/
Two things I noticed:
- Virtualbox spans up *quite* the tree of windows. What is that all about?
- Periodically (and I assume when the weird resizes happen) different VirtualBox windows start spamming i3 with client messages revolving around _NET_WM_STATE_ABOVE and _NET_WM_STATE_BELOW. It seems like each window sends one pair of those two. Neither of those are supported by i3 (and i3 doesn't claim to support either in _NET_SUPPORTED.) I'm getting the feeling this is related to the issue, perhaps different VirtualBox windows are somehow fighting with each other, possibly because i3 doesn't do what they want us to do?
Can the VirtualBox guys explain what this window tree is all about? Is it supposed to be like that? Also perhaps the client messages can give a hint of which code path is acting out(?)
I'll attach a file that contains the entire tree spanned by VirtualBox.
comment:16 by , 8 years ago
I actually think this is not directly related to window manager involvement. Despite the weird size(s) of the VM, VirtualBox's window does have the full size, so whatever VirtualBox does there, it does it within its window – and what happens inside a client window is the client's job, i3 knows nothing about that.
Of course it likely has indirectly to do with i3 because I assume VirtualBox is trying to figure out its size or something. I think it'd be useful if you could figure out based on what VirtualBox triggers the resizes and then we can look at how i3 provides this information differently than other window managers and whether it's an i3 issue or a VirtualBox issue.
comment:17 by , 8 years ago
Airblader, thank you for taking the time to look at this. Unfortunately I am not the UI developer, who is rather overloaded with tasks already, though I do have some knowledge of that code. I'm afraid I don't know either why we use quite that many windows - I think it is probably due to Qt using native windows for widgets (which it sometimes does and sometimes does not). The client messages almost certainly come from Qt, based on the scientific reasoning that I find that text in the Qt Xcb integration code and not in our sources (and I tend to know what code of ours sends client messages).
The reason that you can't run VirtualBox under xtrace is probably that it is setuid. Not quite sure how to get round that, as it is not actually meant to be run as root (it drops privileges pretty fast). I wonder if there are any tools to do the tracing on the X server side.
Now some questions of mine, given that I have never used a tiling window manager. VirtualBox's default behaviour, when auto-resizing is enabled, is to adjust the desktop size of the virtual machine it is running to match the size of the window it is displayed in whenever that changes. I would naively assume that it was i3 which was forcing the host window to a certain size, and generally we try to fit in with what the window manager wants. Given that background, how correct or incorrect does the behaviour appear to you?
comment:18 by , 8 years ago
Looking at the description of XTrace it does not look as if the setuid process should be a problem. Try running a virtual machine process directly:
$ DISPLAY=:<n> VirtualBox --startvm <machine name or UUID>
comment:19 by , 8 years ago
Thanks for the feedback! I guess QT doing all of those things makes sense (in a way – QT asking i3 to do things it doesn't claim to support is a spec violation, but whatever.)
VirtualBox's default behaviour, when auto-resizing is enabled, is to adjust the desktop size of the virtual machine it is running to match the size of the window it is displayed in whenever that changes.
Can you point me towards the relevant parts in VirtualBox's source code? I think if I took a look at it I might get a better bigger picture.
I would naively assume that it was i3 which was forcing the host window to a certain size, and generally we try to fit in with what the window manager wants. Given that background, how correct or incorrect does the behaviour appear to you?
Your description sounds fine. The client (VirtualBox) asks to be a certain size or in a certain position. A typical (floating) WM will simply grant that. Tiling window managers will deny the request and instead force the position and geometry on the client. This comes back to the client in the form of a ConfigureNotify event. The crucial part is that the client actually waits for this event and uses its value, some clients make the mistake of assuming their request will be honored.
I'm confident that QT is not doing anything wrong here, it's an established tool that generally works just fine with i3. I'm not sure how QT works, though, since I never used it mysel, so I'd like looking at how VirtualBox interacts with QT here.
Try running a virtual machine process directly:
I'll try that tomorrow. I really think an xtrace could help a lot here. It would allow us to see whether X, i3 or VirtualBox/QT request the size changes.
Also here's an issue over at awesome (another tiling WM) which sounds fairly similar; it might be the same: https://github.com/awesomeWM/awesome/issues/1015
comment:20 by , 8 years ago
Running VirtualBox under xtrace just doesn't work for me. It just stops dead after half a second and nothing ever happens. Tomorrow I think I might just try doing it in reverse and running i3 under xtrace.
comment:21 by , 8 years ago
Hello, I am one of AwesomeWM developer. Someone pointed us here. We also had reports of this issue and another of our developer investigated it a bit:
comment:22 by , 8 years ago
I couldn't resist and just tried right now. :-) Unfortunately it didn't go any better. I tried both xtrace and xscope. I'm pretty sure I've ran i3 under xtrace before, but other applications seem to run fine under xtrace, so I'm not sure what the problem is.
The comment by psychon in the linked awesomeWM ticket, while harsh, looks pretty worrying to me. If this is still in the VirtualBox code and the code path triggered here it might have to do with the issue.
comment:23 by , 8 years ago
I have i3 set to always treat virtualbox windows as floating and it always defaults to the small size from above. So in my case i3 shouldn't be telling virtualbox what size to use, it should be virtualbox that's telling i3 what size to make the window.
comment:24 by , 8 years ago
I will write up a bit of documentation on our wiki regarding resizing when I get a moment (as you can guess it is not completely simple). But I can reassure you regarding that code that you found. That is part of our 3D pass-though code, which only executes on the guest (and is interacting with windows and usually a window manager which purely exist inside the guest), and which is horribly ugly. It is basically an old project by Brian Paul to pack OpenGL over a network link and render it on a different machine, which was made to work in X11 guests by programmers mainly from a Windows background. The comment is still from the original project.
Will continue later.
comment:25 by , 8 years ago
First draft done<1>. More to come if I find time, including full-screen. Normally we will not try to force a window onto a particular screen if I remember right (I think we did previously), possibly except if the window manager does not support the EWMH full-screen window-to-screen mapping request.
comment:26 by , 8 years ago
Thanks for that, already. For me to use this to dig into the VirtualBox source, however, I'd need a bit more detail as to what those events actually are. Something I can use with grep, basically. :-)
It'd also be good if affected users could try and xtrace this issue. Perhaps others have more luck than me.
by , 8 years ago
Attachment: | x11trace_vbox.zip added |
---|
comment:27 by , 8 years ago
Thanks @michael and @Airblader for looking into this.
@Airblader: xtrace (or x11trace on Arch) is working for me when used together with the '-e' switch which turns off all (forwarded) extensions.
I have attached the log output of a session where virtualbox was running in i3 and where I've switched layout a couple of times. HTH.
follow-up: 29 comment:28 by , 8 years ago
I am still not sure whether everyone is reporting the same issue here. But what I seem to see from Will's log file and from the video on nfb's Debian bug is someone outside - presumably i3 - repeatedly telling the virtual machine window to resize in a not-quite-consistent manner (perhaps related to the tiling concept) and VirtualBox doing its best to fulfil the request. Will, I saw your comment that the window is set to "floating", nonetheless that is what I see in the log.
Airblader, does that sound at all likely? Not sure if you really want to dive into the VirtualBox source at this point, it really is quite complex. You might be better asking me what you want to look for.
follow-up: 36 comment:29 by , 8 years ago
Replying to michael:
I am still not sure whether everyone is reporting the same issue here. But what I seem to see from Will's log file and from the video on nfb's Debian bug is someone outside - presumably i3 - repeatedly telling the virtual machine window to resize in a not-quite-consistent manner (perhaps related to the tiling concept) and VirtualBox doing its best to fulfil the request. Will, I saw your comment that the window is set to "floating", nonetheless that is what I see in the log.
I think what you're seeing in the log is me trying to resize the floating window. When the automatic resize is turned on the window keeps setting itself to 271x64 even when I drag it to make it larger.
follow-up: 37 comment:30 by , 8 years ago
Looking at the xtrace (thanks for that!) I see that over the course of the log, 25 windows execute a total of 263 ConfigureWindow requests. It's always a triple of updating WM_NORMAL_HINTS, requesting ConfigureWindow and receiving ConfigureNotify. All of these requests seem to be confirmed, but I doubt by i3. I assume most of these windows are _not_ top-level and therefore handled by X itself (which is why they're confirmed unchanged.) I'm not sure this is the problem we see, but it seems likely to me.
@afwlehmann How long did you have VirtualBox running for?
@michael Can you figure out under which circumstances VirtualBox sets WM_NORMAL_HINTS? A quick grep through the source against your recommendation ( :-) ) would lead me to believe it might be src/VBox/RDP/client-1.8.3/xwin.c, more specifically the function ui_resize_window. It's the only one that calls XSetNormalWMHints and then XResizeWindow right after which would fit the pattern I see in the xtrace. Of course I have no idea what this code path is related to.
comment:31 by , 8 years ago
@Airblader: Not for very long. I just fired it up and had the virtual machine running for less than a minute while doing those container layout changes, e.g. switch between horizontal and vertical tiling.
comment:32 by , 8 years ago
@afwlehmann OK, thanks. With 25 windows and a few triggered switches 263 requests may not necessarily be »oddly many«, but it still shows that the resize is triggered by VirtualBox. I'll recheck the log to see if there's any ConfigureNotify without prior ConfigureRequest that look weird, though.
follow-up: 39 comment:33 by , 8 years ago
Aren't we dealing with displaying issues rather than resizing issues? Taking a look at https://ptpb.pw/FOrS.jpg I see huge scrollbars which shoot out the left part of the picture. So the resizing does actually work. At least in my case it definitely works but in order to display the whole thing right I have to restart i3. Furthermore if I start a vm without guestadditions, auto-resizing functionality etc. it is displayed on the top-left corner of the window which is an unusual behavior for virtualbox because it did always display the virtual screen on the center of the window and vb actually still does it but after restarting i3. I will append two screenshots to illustrate my experience. Maybe michael is right and I'm facing another issue? But if not, why does nobody care about the fact that restarting i3 does actually help in some way? Or does it only work for me? I don't know how to track the communication between i3 and vb, but how does the communication differ when restarting i3?
by , 8 years ago
Attachment: | issue2.JPG added |
---|
Broken and fixed display of a vm without auto-resizing functionality
by , 8 years ago
Broken and fixed display of a vm with auto-resizing functionality
follow-up: 40 comment:34 by , 8 years ago
It could be either a resize or display issue. The easy answer to that is: do the scrollbars work? If so, it's a resize issue (and I assume this is the case.) However, it's worth pointing out that the incorrect resize is happening in a subwindow of VirtualBox – i3 doesn't interact with these windows.
The visual garbage around the guest display is simply due to VirtualBox not rendering this area when X sends an Expose event, I presume. This is probably just a consequence of the bug at hand – VirtualBox thinks its window has a different size than it actually has.
I still think we need to understand based on what exactly VirtualBox resizes the guest display. Then we know what to look for (hopefully.)
by , 8 years ago
Attachment: | xtrace.awesomwm.virtualbox.zip added |
---|
xtrace log of my issue with auto-resize
follow-up: 41 comment:35 by , 8 years ago
I'm the OP of the awesomewm issue. I attached what I believe is an xtrace log of the interaction. What I did was basically start up a VM, move it to the second screen, it jumps back by itself to the first screen and then I quit the VM.
follow-up: 54 comment:36 by , 8 years ago
Replying to Will Everett:
I think what you're seeing in the log is me trying to resize the floating window. When the automatic resize is turned on the window keeps setting itself to 271x64 even when I drag it to make it larger.
How did you try to resize it? By resizing the window on the host? I do not see any resize requests making it to VirtualBox except for those 271x64 ones, which at least to me suggests that if that is what you are doing something intercepts them before they reach us.
comment:37 by , 8 years ago
Replying to Airblader:
@michael Can you figure out under which circumstances VirtualBox sets WM_NORMAL_HINTS? A quick grep through the source against your recommendation ( :-) ) would lead me to believe it might be src/VBox/RDP/client-1.8.3/xwin.c, more specifically the function ui_resize_window. It's the only one that calls XSetNormalWMHints and then XResizeWindow right after which would fit the pattern I see in the xtrace. Of course I have no idea what this code path is related to.
I tried my best! The code you found is inside the rdesktop fork with USB pass-through functionality, which we ship for people wanting to access machines remotely. It is not executed in non-RDP use, and not in the VirtualBox binary even then.
I believe that the WM_NORMAL_HINTS originates from void QXcbWindow::propagateSizeHints() inside Qt. Working out the call chain down to there is something I have not yet attempted (if anyone reading this who is experiencing the issue has debug symbols for VirtualBox and Qt installed, they could find this out quickly with breakpoints in gdb).
comment:38 by , 8 years ago
Here is the output from gdb when I put a break-point on that method, resize the machine window in the host once by dragging with the mouse and print out the stack trace every time it subsequently stops. Qt has many good sides, but keeping things simple is not always one of them.
by , 8 years ago
Attachment: | backtraces.log added |
---|
gdb back-traces when I resize with a breakpoint on QXcbWindow::propagateSizeHints()
comment:39 by , 8 years ago
Replying to 1337:
Aren't we dealing with displaying issues rather than resizing issues? Taking a look at https://ptpb.pw/FOrS.jpg I see huge scrollbars which shoot out the left part of the picture.
Scroll-bars are shown when the host window size is too small for the mode set on the virtual output mapping to that window. It looks to me like when you restart i3 it resizes the window and the virtual machine reacts by setting a matching mode on that output. In the "broken" picture with auto-resizing, the real window size is clearly too small for the mode for some reason.
comment:40 by , 8 years ago
Replying to Airblader:
It could be either a resize or display issue. The easy answer to that is: do the scrollbars work? If so, it's a resize issue (and I assume this is the case.) However, it's worth pointing out that the incorrect resize is happening in a subwindow of VirtualBox – i3 doesn't interact with these windows.
The visual garbage around the guest display is simply due to VirtualBox not rendering this area when X sends an Expose event, I presume. This is probably just a consequence of the bug at hand – VirtualBox thinks its window has a different size than it actually has.
I still think we need to understand based on what exactly VirtualBox resizes the guest display. Then we know what to look for (hopefully.)
I am not very skilled at reading X traces (feel free to give hints). Can you tell from the trace that the top-level window belongs to VirtualBox, and that it is not something the VirtualBox window is reparented to? The status bar at the bottom of the window should always be expanded by Qt to fill out the full width of our top-level window, so if there is a mismatch there then somehow Qt has failed to notice the top-level window being resized. (Sorry if I am talking about VirtualBox and Qt as two separate entities here. I realise that from i3's point of view they are one client. But Qt very much has its own code flows.)
comment:41 by , 8 years ago
Replying to nickez:
I'm the OP of the awesomewm issue. I attached what I believe is an xtrace log of the interaction. What I did was basically start up a VM, move it to the second screen, it jumps back by itself to the first screen and then I quit the VM.
The problem description sounds sufficiently different to what the i3 people are talking about that I think it does not belong on this ticket. Please talk to the Awesome developers about this, and if you think that it is a VirtualBox issue we might want to see if I can investigate it with them.
comment:42 by , 8 years ago
Will Everett, could you please do a screen recording of what you are seeing? To help me visualise.
comment:43 by , 8 years ago
I see the following sequence of events in the xtrace:
000:>:5053: Event (generated) ConfigureNotify(22) event=0x0340000e window=0x0340000e above-sibling=None(0x00000000) x=2 y=725 width=1916 height=333 border-width=0 override-redirect=false(0x00) 000:<:5054: 28: Request(12): ConfigureWindow window=0x0340001a values={x=0 y=0 width=476 height=292} 000:>:5054: Event ConfigureNotify(22) event=0x0340002e window=0x0340002e above-sibling=None(0x00000000) x=185 y=3 width=267 height=17 border-width=0 override-redirect=false(0x00) [...] 000:<:5056: 28: Request(12): ConfigureWindow window=0x03400026 values={x=0 y=0 width=476 height=19}
It looks to me like someone (i3) is sending a generated ConfigureNotify to us not backed by a real one. And I see this code in Qt:
void QXcbWindow::handleConfigureNotifyEvent(const xcb_configure_notify_event_t * event) { bool fromSendEvent = (event->response_type & 0x80); [...]
So Qt definitely handles generated ConfigureNotify events slightly differently.
comment:44 by , 8 years ago
Actually that is just a special case to double check the position co-ordinates if the event is not generated.
comment:45 by , 8 years ago
Interesting - the width in the two ConfigureWindow requests is 1440 pixels smaller than that in the first ConfigureNotify event. 1440 is (still just) a not uncommon laptop screen width.
follow-up: 47 comment:46 by , 8 years ago
afwlehmann, would you be able to describe exactly what you did when you got that trace? And do you have a screen with a 1440 pixel width?
follow-up: 55 comment:47 by , 8 years ago
Replying to michael:
afwlehmann, would you be able to describe exactly what you did when you got that trace? And do you have a screen with a 1440 pixel width?
The screen has a phyiscal (and logical) resolution of 1920x1080. When I started the virtual machine (being an Ubuntu guest in this case) i3 split the screen vertically, the VM was on the right-hand side. Therefore the window should have had something roughly like 960x1080. I've subsequently switched a few times back and forth between horizontal and vertical layout (960x1080 vs. 1920x540).
If there's a certain scenario that you would like to see I am more than happy to provide the corresponding trace.
follow-up: 53 comment:48 by , 8 years ago
You did not answer exactly the question I asked, though perhaps you intended your answer to be understood that way. Do you have any other screens in use of 1440 pixels wide? I am just wondering how that interesting number appeared.
follow-up: 50 comment:49 by , 8 years ago
It looks to me like when you restart i3 it resizes the window
Let's take a step back and go through some basics of X11 window management. In its role as a window manager, i3 will select SubstructureRedirect on the root window. This will cause the X server to send requests such as mapping or reconfiguring top-level windows (direct children of root) to i3 which can then handle these events.
However, this does not(!) affect any subwindows of top-level windows. Requests for those go directly to X and X will usually just acknowledge them and confirm them with the corresponding notification (ConfigureWindow → ConfigureNotify).
Looking at the screenshot one can see that the statusbar of the VirtualBox window extends across the entire width of what i3 wants the window to be. This proves that the top-level window has the correct size (since a window cannot render outside of its geometry). The »broken« part – i.e., the guest display with the scrollbars – seems to be a subwindow. How this window is sized is entirely up to the client (VirtualBox / QT).
Can you tell from the trace that the top-level window belongs to VirtualBox, and that it is not something the VirtualBox window is reparented to?
You mean detecting whether it's the top-level window or a subwindow within the VirtualBox window? Sure. Pick a window ID, any window ID – let's say 0x0340000e. Now look in the log file for the CreateWindow request:
000:<:0103: 60: Request(1): CreateWindow depth=0x18 window=0x0340000e parent=0x000000d7 x=0 y=0 width=640 height=480 border-width=0 class=InputOutput(0x0001) visual=0x00000020 value-list={background-pixmap=None(0x00000000) border-pixel=0x00000000 bit-gravity=NorthWest(0x01) override-redirect=false(0x00) save-under=false(0x00) event-mask=KeyPress,KeyRelease,ButtonPress,ButtonRelease,EnterWindow,LeaveWindow,PointerMotion,ButtonMotion,Exposure,StructureNotify,FocusChange,PropertyChange colormap=0x0340000d}
This says "parent=0x000000d7". Now typically you'd need the X tree to determine whether 0x000000d7 is the root window (which we can't do anymore), but we can also use a trick: let's just see what else the log file says about 0x000000d7. We see all the way on top this little guy:
000:<:0003: 24: Request(20): GetProperty delete=false(0x00) window=0x000000d7 property=0x17("RESOURCE_MANAGER") type=0x1f("STRING") long-offset=0x00000000 long-length=0x05f5e100
RESOURCE_MANAGER is a root wndow property that nobody would have any business querying on any child of it, so I'd say 0x000000d7 is indeed our root window and 0x0340000e thus is a top-level window. There's plenty other similar properties queried on this parent that confirm this as well.
It looks to me like someone (i3) is sending a generated ConfigureNotify to us not backed by a real one.
Correct, we do send a faked ConfigureNotify – when we reject ConfigureWindow requests because they are tiled and aren't allowed to change size. This is totally fine, though.
comment:50 by , 8 years ago
Replying to Airblader:
Looking at the screenshot one can see that the statusbar of the VirtualBox window extends across the entire width of what i3 wants the window to be. This proves that the top-level window has the correct size (since a window cannot render outside of its geometry).
Just a drive-by comment... Have you verified whether that status bar is actually live and not some unrepainted leftovers? I.e. which of the two (or more :) status bars that you can see actually responds to e.g. mouse input (right clicks, tool tips on hover)? E.g. note that on issue.JPG
the keyboard state indicator (a "key" with an arrow to the left of the rightmost Strg Rechts
) has different states in the two status bars simultaneously present on the screen, so one of them must be dead pixels in some parent window.
comment:51 by , 8 years ago
Have you verified whether that status bar is actually live and not some unrepainted leftovers?
Good call – it indeed just is leftover garbage. Nonetheless, inspecting the window with xwininfo still yields that the window actually has the full size. Plus if it wasn't like that, there wouldn't be a dead area where visual garbage collects.
comment:52 by , 8 years ago
I've added a screenshot where I used xev when triggering the auroresize. You can see that the event reported to the window has the correct width and height there as well.
comment:53 by , 8 years ago
Replying to michael:
You did not answer exactly the question I asked, though perhaps you intended your answer to be understood that way. Do you have any other screens in use of 1440 pixels wide? I am just wondering how that interesting number appeared.
No other screens at the moment.
comment:54 by , 8 years ago
Replying to michael:
Replying to Will Everett:
I think what you're seeing in the log is me trying to resize the floating window. When the automatic resize is turned on the window keeps setting itself to 271x64 even when I drag it to make it larger.
How did you try to resize it? By resizing the window on the host? I do not see any resize requests making it to VirtualBox except for those 271x64 ones, which at least to me suggests that if that is what you are doing something intercepts them before they reach us.
Yes, I'm resizing by changing the window dimensions on the host. If the "automatic resize" is on in virtualbox as soon as I release the corner of the window it snaps back to the 271x64 size.
comment:55 by , 8 years ago
Replying to afwlehmann:
The screen has a phyiscal (and logical) resolution of 1920x1080. When I started the virtual machine (being an Ubuntu guest in this case) i3 split the screen vertically, the VM was on the right-hand side. Therefore the window should have had something roughly like 960x1080. I've subsequently switched a few times back and forth between horizontal and vertical layout (960x1080 vs. 1920x540).
Here are the size events which I see presumably coming from i3. Do they make sense to you?
000:>:03a3: Event (generated) ConfigureNotify(22) event=0x0340000e window=0x0340000e above-sibling=None(0x00000000) x=1442 y=18 width=476 height=1040 border-width=0 override-redirect=false(0x00) 000:>:03c7: Event (generated) ConfigureNotify(22) event=0x0340000e window=0x0340000e above-sibling=None(0x00000000) x=1442 y=18 width=476 height=1040 border-width=0 override-redirect=false(0x00) 000:>:0870: Event (generated) ConfigureNotify(22) event=0x0340000e window=0x0340000e above-sibling=None(0x00000000) x=1282 y=18 width=636 height=1040 border-width=0 override-redirect=false(0x00) 000:>:0d08: Event (generated) ConfigureNotify(22) event=0x0340000e window=0x0340000e above-sibling=None(0x00000000) x=1282 y=18 width=636 height=1040 border-width=0 override-redirect=false(0x00) 000:>:0f73: Event (generated) ConfigureNotify(22) event=0x0340000e window=0x0340000e above-sibling=None(0x00000000) x=1282 y=18 width=636 height=1040 border-width=0 override-redirect=false(0x00) 000:>:13b5: Event (generated) ConfigureNotify(22) event=0x0340000e window=0x0340000e above-sibling=None(0x00000000) x=1282 y=18 width=636 height=1040 border-width=0 override-redirect=false(0x00) 000:>:15cc: Event (generated) ConfigureNotify(22) event=0x0340000e window=0x0340000e above-sibling=None(0x00000000) x=1282 y=18 width=636 height=1040 border-width=0 override-redirect=false(0x00) 000:>:1ab7: Event (generated) ConfigureNotify(22) event=0x0340000e window=0x0340000e above-sibling=None(0x00000000) x=1282 y=18 width=636 height=1040 border-width=0 override-redirect=false(0x00) 000:>:2047: Event (generated) ConfigureNotify(22) event=0x0340000e window=0x0340000e above-sibling=None(0x00000000) x=1282 y=18 width=636 height=1040 border-width=0 override-redirect=false(0x00) 000:>:225a: Event (generated) ConfigureNotify(22) event=0x0340000e window=0x0340000e above-sibling=None(0x00000000) x=1282 y=18 width=636 height=1040 border-width=0 override-redirect=false(0x00) 000:>:36a5: Event (generated) ConfigureNotify(22) event=0x0340000e window=0x0340000e above-sibling=None(0x00000000) x=2 y=725 width=1916 height=333 border-width=0 override-redirect=false(0x00) 000:>:3b75: Event (generated) ConfigureNotify(22) event=0x0340000e window=0x0340000e above-sibling=None(0x00000000) x=2 y=725 width=1916 height=333 border-width=0 override-redirect=false(0x00) 000:>:4189: Event (generated) ConfigureNotify(22) event=0x0340000e window=0x0340000e above-sibling=None(0x00000000) x=1282 y=18 width=636 height=1040 border-width=0 override-redirect=false(0x00) 000:>:43ee: Event (generated) ConfigureNotify(22) event=0x0340000e window=0x0340000e above-sibling=None(0x00000000) x=1282 y=18 width=636 height=1040 border-width=0 override-redirect=false(0x00) 000:>:4c13: Event (generated) ConfigureNotify(22) event=0x0340000e window=0x0340000e above-sibling=None(0x00000000) x=2 y=725 width=1916 height=333 border-width=0 override-redirect=false(0x00) 000:>:5053: Event (generated) ConfigureNotify(22) event=0x0340000e window=0x0340000e above-sibling=None(0x00000000) x=2 y=725 width=1916 height=333 border-width=0 override-redirect=false(0x00) 000:>:55ba: Event (generated) ConfigureNotify(22) event=0x0340000e window=0x0340000e above-sibling=None(0x00000000) x=2 y=548 width=1916 height=510 border-width=0 override-redirect=false(0x00) 000:>:5809: Event (generated) ConfigureNotify(22) event=0x0340000e window=0x0340000e above-sibling=None(0x00000000) x=2 y=548 width=1916 height=510 border-width=0 override-redirect=false(0x00) 000:>:684a: Event (generated) ConfigureNotify(22) event=0x0340000e window=0x0340000e above-sibling=None(0x00000000) x=2 y=548 width=1916 height=510 border-width=0 override-redirect=false(0x00)
comment:56 by , 8 years ago
Note that the exact value is different from what @afwlehmann as an end user would expect because things like window borders and decoration have been subtracted from the window size. Also note that these are the responses by i3 and not the requests. You can see that until the user changed from horiztonal to vertical layout, i3 always sends the same geometry in the response because it answers the VirtualBox request with »nope, you'll stay this size.« When layout is switched to vertical, i3 resizes the window and thus now reports a different size in the response.
comment:57 by , 8 years ago
I would be interested if someone could log (using gdb or whatever) calls to QXcbWindow::handleConfigureNotifyEvent(), UIMachineWindowNormal::event(), UIMachineView::eventFilter() and UIMachineView::resizeEvent() with parameters immediately after a resizing goes wrong inside the VirtualBox process. It may help with this if you start the machine process directly from the command line with "VirtualBox --startvm <machine name>". Checking that the events are really resize events would of course be helpful if possible.
comment:58 by , 8 years ago
I can reproduce something which looks similar by triggering a resize using "xrandr" in a guest, intercepting the call to xcb_configure_window for the main window in gdb (inside the VirtualBox process on the host of course) and forcing the width and height back to their old/current values.
comment:59 by , 8 years ago
Oh dear, this comment in the Qt 5.6 source code (src/plugins/platforms/xcb/qxcbwindow.cpp, QXcbWindow::handleConfigureNotifyEvent()) does not look very encouraging:
// FIXME: In the case of the requestedGeometry not matching the actualGeometry due // to e.g. the window manager applying restrictions to the geometry, the application // will never see a move/resize event if the actualGeometry is the same as the current // geometry, and may think the requested geometry was fulfilled.
comment:60 by , 8 years ago
@michael This is exactly why i3 sends a faked ConfigureNotify (even though it doesn't have to.)
comment:61 by , 8 years ago
Which I suspect Qt kindly filters out for us when it sees that there was no real change.
comment:62 by , 8 years ago
Which shouldn't be a problem either. VirtualBox should not render based on the request it makes but based on the event it gets (however this works in detail with QT.) :-)
comment:63 by , 8 years ago
Since we are a cross-platform application and use Qt for interacting with the different host systems we are rather dependent on the way Qt works, and Qt is sometimes somewhat over-eager to hide what is happening underneath; the trick will probably be to find the least intrusive way to persuade Qt not to ignore this event and not to hide it from us.
comment:64 by , 8 years ago
I don't quite follow. QT hiding the no-op event should only be a problem if VirtualBox assumes its resize requests to succeed unconditionally. And if this is the case, VirtualBox is clearly violating the X11 specification. The fact that it's cross-platform doesn't change that, you still need to comply with how a specific platform works.
And even if you get QT to report the event it would still mean that VirtualBox first makes an incorrect assumption and is corrected shortly after. Which means you'd nullify the effect of the bug quickly, but the bug would still exist.
But perhaps I'm misunderstanding something?
comment:65 by , 8 years ago
As far as I can see (I am not actually our Qt person, Linux/X11 is more my area, and Qt as far as it intersects with those), when we ask Qt to resize the main window it proactively resizes all the sub-windows - of which it, not we controls the geometry - assuming that the resize request will succeed. Finding the best way of telling that the request failed, probably by breaking into Qt's event queue before it can filter the event out (if that is indeed what is happening) to at least nullify the effect as you put it would be one way. A separate code path on X11 hosts calling xcb_configure_window() directly rather than setting the geometry through Qt, so that Qt only learns about the change from the resize event, would be another - and hoping that there are no unwanted side effects.
Again, assuming that my analysis is actually right, which is definitely not guaranteed at this point.
I am currently going through the Qt code trying to follow the paths; unfortunately Qt is like C++ in that respect: to understand it properly you need to devote your whole time to it, and not try to do other things in parallel, like using it to create applications.
comment:66 by , 8 years ago
when we ask Qt to resize the main window it proactively resizes all the sub-windows - of which it, not we controls the geometry - assuming that the resize request will succeed
I see. If this is indeed the case I think this should also be brought to the attention of the QT guys. Perhaps they shouldn't make that assumption and resize the subwindows? But in a complex nested tree this would involve a lot of waiting and state holding. It's certainly an uncomfortable situation. Perhaps they also shouldn't filter such events then (if that's what they do.)
comment:68 by , 8 years ago
If anyone subscribed to this ticket is building themself, they might like to try out the following patch. I will try to get test builds done tomorrow or the day after.
Index: src/VBox/Frontends/VirtualBox/src/runtime/normal/UIMachineWindowNormal.cpp =================================================================== --- src/VBox/Frontends/VirtualBox/src/runtime/normal/UIMachineWindowNormal.cpp (revision 111261) +++ src/VBox/Frontends/VirtualBox/src/runtime/normal/UIMachineWindowNormal.cpp (working copy) @@ -25,6 +25,10 @@ # include <QContextMenuEvent> # include <QResizeEvent> # include <QScrollBar> +# ifdef VBOX_WS_X11 +# include <QX11Info> +# include <xcb/xcb.h> +# endif /* GUI includes: */ # include "VBoxGlobal.h" @@ -574,8 +578,27 @@ frGeo = VBoxGlobal::normalizeGeometry(frGeo, gpDesktop->overallAvailableRegion()); /* Finally, set the frame geometry: */ - setGeometry(frGeo.left() + dl, frGeo.top() + dt, - frGeo.width() - dl - dr, frGeo.height() - dt - db); + int x, y, w, h; + x = frGeo.left() + dl; + y = frGeo.top() + dt; + w = frGeo.width() - dl - dr; + h = frGeo.height() - dt - db; +#if defined(VBOX_WS_X11) && QT_VERSION >= 0x050000 + /* X11 window managers are not required to accept geometry changes on + * the top-level window. Unfortunately, current at Qt 5.6 and 5.7, Qt + * assumes that the change will succeed, and resizes all sub-windows + * unconditionally. By calling ConfigureWindow directly, Qt will not + * see our change request until the ConfigureNotify event on success + * and not at all if it is rejected. */ + uint16_t fMask = XCB_CONFIG_WINDOW_X | XCB_CONFIG_WINDOW_Y + | XCB_CONFIG_WINDOW_WIDTH | XCB_CONFIG_WINDOW_HEIGHT; + uint32_t values[] = { (uint32_t)x, (uint32_t)y, (uint32_t)w, (uint32_t)h }; + xcb_configure_window(QX11Info::connection(), (xcb_window_t)winId(), + fMask, values); + xcb_flush(QX11Info::connection()); +# else + setGeometry(x, y, w, h); +# endif #else /* VBOX_GUI_WITH_CUSTOMIZATIONS1 */ /* Customer request: There should no be * machine-window resize/move on machine-view resize: */
comment:69 by , 8 years ago
Tried it, but it seems that nothing changed so far. I did the following:
- Built the latest SVN checkout
- Built (and insmod) the kernel modules
- Ran
VBoxManage startvm {...}
- Switched layout a couple of times, also tried full-screen (i3's fullscreen, to be precise)
follow-up: 71 comment:70 by , 8 years ago
Replying to michael:
If anyone subscribed to this ticket is building themself, they might like to try out the following patch. I will try to get test builds done tomorrow or the day after.
Thank you Michael. I rebuilt the VirtualBox debian package from source, using your patch. Seems to be working correctly in tiled mode with wmii.
However, if I switch to floating mode, where windows are treated just like in classical window managers, the window sticks to 0x0 size, and moves to the upper left corner.
comment:71 by , 8 years ago
Replying to fgalea:
However, if I switch to floating mode, where windows are treated just like in classical window managers, the window sticks to 0x0 size, and moves to the upper left corner.
The patch seems to completely bypass all the code to set WM
hints etc, so I guess when you switch to the floating mode, the missing (or all zero) hints confuse the WM.
I think this really should be taken up with Qt. It's a Qt5 bug (Qt4 seems fine) you can reproduce with the simplest app. Trying to work around this at the application will be extremely fragile and counterproductive.
by , 8 years ago
Attachment: | i3-qt5-test.png added |
---|
Simple test app that resizes its window (never mind the "Move" caption :) and demonstrates the Qt5 bug.
comment:74 by , 8 years ago
Works like a charm in i3 except for floating windows for which resizing is still broken. But it's definitely something I can work with. Thanks a lot!
comment:75 by , 8 years ago
Same for me with wmii. The behavior is the same as with the previous patch.
comment:76 by , 8 years ago
In those cases which do not work, I would be interested in seeing the output of xprop on the problematic window with and without the patch.
comment:77 by , 8 years ago
Just to be clear, I hope that the output I asked for will help find out why the floating window mode is not working with the change. I would rather not leave the change in though if I can't find that out, since given that there are regressions even with this small amount of testing chances are quite high that there will be more if the change lands in a release, and that the change will overall be for the worse.
More generally, the team was not happy with the idea of keeping this change in the long term to work around a Qt bug (which the Qt team are clearly aware of<1>), so we suggest that someone should take this up with them and strongly suggest that they back-port it to 5.6, which we will be sticking to for now.
<1> http://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/xcb/qxcbwindow.cpp?h=5.8#n2125
comment:78 by , 8 years ago
My patch to VirtualBox should actually be a reasonable basis for a fix in Qt.
comment:79 by , 8 years ago
Uploading a slightly modified patch, test builds<1> should be available soon (any build as of revision 111509 should contain the patches, at least as long as they have not been reverted).
by , 8 years ago
Attachment: | r111428-r111430-r111508.patch added |
---|
Current at this time patch against 5.1. May have slight fuzz when applying.
comment:80 by , 8 years ago
Still no feedback. New test builds<1> available. Patch to follow. As things stand we can't leave these changes in though, due to the known regressions in floating mode.
comment:81 by , 8 years ago
I can confirm that the test build 5.1.x revision 111573 does fix the issue.
comment:82 by , 8 years ago
I've tested 5.1.x revision 111643. It works fine. Thanks for your hard work @michael .
comment:83 by , 8 years ago
I would very much like to have confirmation that the floating window regression is fixed (and possibly that another regression is too), if indeed it is, before I take this change into a release.
comment:84 by , 8 years ago
Works for me in tiling mode, but not in floating mode (tried both a Windows 10 as well as a Ubuntu client).
comment:85 by , 8 years ago
Thanks for checking. That means though that unless someone can find out what is wrong we will probably not be able to include the fix in future releases. In any case someone needs to open a Qt bug for this to get it fixed at source.
comment:86 by , 8 years ago
I've been stuck in 5.0 version due this bug. I've found this thread and tested testbuild Version 5.1.9 r111724. I can confirm tiling mode works as expected. But if I change to floating mode and try to resize window, it disappears. It returns when I switch back to tiling mode. Host: Fedora 24, dwm 6.1, Qt 5.6.1 - Guest: Windows 7. I wish to thank for the fix.
follow-ups: 90 91 comment:87 by , 8 years ago
Please give build revision 111900 a try both in tiling and in floating mode. This build does not contain any fix, just a temporary work-around (which can not be kept because it is known to cause other problems).
Linux 32-bit: https://www.virtualbox.org/download/testcase/VirtualBox-5.1.9-111900-Linux_x86.run
Linux 64-bit: https://www.virtualbox.org/download/testcase/VirtualBox-5.1.9-111900-Linux_amd64.run
Linux EL5 64-bit: https://www.virtualbox.org/download/testcase/VirtualBox-5.1-5.1.9_111900_el5-1.x86_64.rpm
Linux EL6 64-bit: https://www.virtualbox.org/download/testcase/VirtualBox-5.1-5.1.9_111900_el6-1.x86_64.rpm
Linux EL7 64-bit: https://www.virtualbox.org/download/testcase/VirtualBox-5.1-5.1.9_111900_el7-1.x86_64.rpm
comment:88 by , 8 years ago
Summary: | auto-resize is broken. → Auto-Resize is broken with tiling window managers |
---|
by , 8 years ago
Attachment: | screenshots.png added |
---|
comment:89 by , 8 years ago
I've tested revision 111900: Tiling mode works ok. Switching to floating mode makes VB window disappear. Switching back to tiling mode makes VB return, but wrong size. See attachment.
comment:90 by , 8 years ago
Replying to michael:
Please give build revision 111900 a try both in tiling and in floating mode. This build does not contain any fix, just a temporary work-around (which can not be kept because it is known to cause other problems).
I confirm that 111900 works as expected in i3wm.
comment:91 by , 8 years ago
Replying to michael:
Please give build revision 111900 a try both in tiling and in floating mode. This build does not contain any fix, just a temporary work-around (which can not be kept because it is known to cause other problems).
Has this been reported to QT? I "upgraded" from 5.1.9-111724 to 5.1.10 today and got the resize bug again. I guess that was suspected since the fix was only temporary and not final?
EDIT: Actually 5.1.11-112052 kind of works if I have the window floating
follow-up: 93 comment:92 by , 8 years ago
I am not aware of anyone having reported this to Qt. I would expect one of the people affected to do so if they consider the issue important enough.
follow-up: 94 comment:93 by , 8 years ago
Replying to nickez:
Has this been reported to QT? I "upgraded" from 5.1.9-111724 to 5.1.10 today and got the resize bug again. I guess that was suspected since the fix was only temporary and not final?
Replying to michael:
I am not aware of anyone having reported this to Qt. I would expect one of the people affected to do so if they consider the issue important enough.
From the related Github issue (https://github.com/i3/i3/issues/2497#issuecomment-266889278) it seems that Nathan Schulte (https://github.com/nmschulte) has created a relevant bug report for the Qt project here: https://bugreports.qt.io/browse/QTBUG-57608
comment:94 by , 8 years ago
Replying to djvdorp:
From the related Github issue (https://github.com/i3/i3/issues/2497#issuecomment-266889278) it seems that Nathan Schulte (https://github.com/nmschulte) has created a relevant bug report for the Qt project here: https://bugreports.qt.io/browse/QTBUG-57608
Great thanks!
comment:95 by , 8 years ago
I'm also having some issues since some update.
When I'm running two monitors, and I move VirtualBox to the second, larger, one, it still keeps the resolution of the main display. Sometimes weird scrollbars even appear.b In seamless mode, however, the resolution is fine.
So the partial workaround I found is to disable auto-resize, switch to seamless mode, and then to full-screen.
VirtualBox Graphical User Interface Version 5.1.14_Gentoo r112924
comment:96 by , 7 years ago
I have recently discovered another issue (#16843) related to the WDDM driver in Windows guests, which I believe is triggered by this auto-resize issue in tiling WMs. (My host system runs i3 on Arch Linux)
In short, the WDDM driver somehow takes the small window size and tries to apply it as Windows' native resolution at boot time, which then fails and renders the guest unresponsive. The value is saved into the registry by the WDDM driver, so a workaround is to modify the offending registry entry immediately after installation of the driver (or revert to a snapshot of the VM pre-GA installation). I have not yet found a way to recover VMs that cannot boot due to this issue yet, as when the registry is mounted offline, the necessary entry for the VirtualBox display adapter does not appear.
For the record, I am running 5.1.22 and still am affected by the resize bug.
comment:97 by , 7 years ago
I suggest its worth taking a look at some of the defects xref from #16240.
On windows, multi-monitor detach was broken for several releases, but on 5.1.22 this seemed specifically to relate to the resize that took place on monitor detach where the detaching monitor is taller than the one that the vm display is moved to, causing the guest vm to crash.
I think it worth testing 5.1.24 in case your issue is now fixed.
comment:98 by , 7 years ago
5.1.24: still broken
5.1.26: more usable, but still broken. On my larger external screen, it tends to resize properly most of the time. Sometimes it doesn't, but moving it between screens tends to fix it. However, I couldn't get rid of scrollbars on my smaller screen UNLESS I open another window on the same screen, which causes window title bar to appear. And even then it doesn't work reliably. https://wgh.torlan.ru/ss/1505849253-te.png https://wgh.torlan.ru/ss/1505849256-oH.png
It's becoming more annoying lately. I could just stay on VirtualBox 5.0.x, but it also prevents me from updating my kernel from 4.9 to newer versions, because VirtualBox 5.0.x kernel module doesn't build on newer kernels.
comment:99 by , 7 years ago
@WGH_ The Qt developers say that this is fixed in the not-yet-released Qt 5.10. Are you running that? And if you are, are you sure that this is a VirtualBox problem and not another Qt one? We have already spent time investigating this which we would rather have spent improving other things.
comment:100 by , 7 years ago
@michael no, I'm not. I'm unable to install development Qt version on my main system due to obvious concerns. I might be able to setup some testing environment later on, and when I do, I will certainly report any findings.
comment:101 by , 7 years ago
Qt 5.10 (which was recently released) fixed the issue for me (I'm running i3).
comment:102 by , 4 years ago
same issue is still happening on latest Manjaro Linux with i3
- virtualbox 6.1.16-1
- qt 5.15.1-1
also the #14323, same behavior... both bugs are still valid (I believe they are related)
It looks like this https://ptpb.pw/FOrS.jpg