https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #18 from Zachary Murray dremelofdeath@gmail.com --- I saw that (#12), which is why I retested it. I am still experiencing the problem even during normal use. I'll add a screenshot to show the chat experience with the Settings window open. And I'm sure the forum will know more, but with respect to this specific issue I don't think there's enough information yet to understand exactly what's causing the issue.
Also, I *don't* see the thick borders issue. From your screenshot it looks like the shadowing effect isn't rendering at all and is just black with no transparency. Maybe it's a compositor issue? Did the shadows render correctly before?
I noticed that we're currently on the same Ubuntu version (16.04) but using different DEs (LXDE for you vs. XFCE for me). I wonder if that makes a difference. Also just checking, but are you running Wine in desktop mode? Per #4 and #16 I think that would fix it but haven't checked.
Update on #16 as well: running with the hack results in other undesirable behavior, such as a blank window appearing randomly (particularly after restoring after iconifying), and after restoring, the borders begin to render incorrectly again, so it's not even a permanent fix.
I examined the border windows before and after this happened and found that Wine is adding a stack mode (Above) to the window state after the restore whereas none is set beforehand. I tried hacking this in the Wine X11 driver to Below instead, which resulted in the border window not appearing at all. Less annoying, but wrong.
The border window has some interesting styles applied, like WS_EX_TOPMOST. The content window doesn't have this. If I understand what LINE is trying to do correctly, it is constantly trying to reposition the border window and keeping it above the contents by continually calling SetWindowPos() on the border window with flags SWP_NOMOVE, SWP_NOSIZE, SWP_NOZORDER, and SWP_SHOWWINDOW set.
I wonder what would happen if WS_EX_TOPMOST were not applied (maybe with a hack). The constant SetWindowPos() calls might be making Wine inadvertently display them above everything where somehow Windows doesn't do that.
One thing I want to try is testing this with a different driver, like Android. If it doesn't manifest there, I think it would indicate a problem in the X11 driver. If it does, I'd want to investigate the user32 windowing code.