https://bugs.winehq.org/show_bug.cgi?id=43030
Bug ID: 43030 Summary: LINE: Window border stays on top of other windows Product: Wine Version: 2.3 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: kristopher@posteo.net Distribution: ---
Created attachment 58181 --> https://bugs.winehq.org/attachment.cgi?id=58181 Screenshot of the behavior
This is using the windows version of LINE from here: https://scdn.line-apps.com/client/win/new/LineInst.exe (App homepage: https://line.me/)
The app seems to have a black border that follows the main window around. You can see it if you move the window around as the border stays in place, and only moves after the window finishes moving. This border stays on top of all other windows.
This behaviour occurs in every window manager or DE that I have tried, so I do not think it's window manager related.
I'm currently on wine-staging, but this has happened with multiple versions of wine.
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #1 from kristopher@posteo.net --- Created attachment 58182 --> https://bugs.winehq.org/attachment.cgi?id=58182 Standard wine output (No debugging)
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #2 from kristopher@posteo.net --- I'd like to add that I've also just run this on a git version of wine: wine-2.8-25-gbe12c5bc4f (Staging) and the problem still persists.
https://bugs.winehq.org/show_bug.cgi?id=43030
kristopher@posteo.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|minor |trivial Version|2.3 |2.8
--- Comment #3 from kristopher@posteo.net --- Sorry for the spam, just updating the version and importance after reading over the guidelines again.
https://bugs.winehq.org/show_bug.cgi?id=43030
張修銘 cges30901@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cges30901@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #4 from Alexandre Julliard julliard@winehq.org --- As far as I can tell, the border window is being moved correctly, but the window manager doesn't process the configure requests until the dragging is finished. It should work fine if you uncheck "allow the window manager to control the windows", or in desktop mode.
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #5 from kristopher@posteo.net --- I guess it didn't sound like it from the original report, but the main problem is not that the border move is delayed. The problem is that the border stays on top off all other windows. The screenshot I attached shows the exact behaviour.
If I disallow the window manager to control the window, then the entire app is always on top, which is the opposite of what I'm looking for, a virtual desktop would do the same as well. But both of those just ignore the problem by forcing the window to not be able to go behind others.
https://bugs.winehq.org/show_bug.cgi?id=43030
Geoffrey love@cvbt-web.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |love@cvbt-web.org
--- Comment #6 from Geoffrey love@cvbt-web.org --- I also this symptom - a black outline of the application window appears on top of other applications when LINE is in the background (behind other windows).
https://bugs.winehq.org/show_bug.cgi?id=43030
badflagello badflagello@hotmail.it changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |badflagello@hotmail.it
--- Comment #7 from badflagello badflagello@hotmail.it --- Problem persist with Wine 3.0. Since the new LINE version (5.6.0.1625) the black border became thicker!
https://bugs.winehq.org/show_bug.cgi?id=43030
Utente Vino utentevino@20boxme.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |utentevino@20boxme.org
--- Comment #8 from Utente Vino utentevino@20boxme.org --- Created attachment 60471 --> https://bugs.winehq.org/attachment.cgi?id=60471 Thick borders LINE 5.6.0.x under Wne 3.0
https://bugs.winehq.org/show_bug.cgi?id=43030
aufa.nabil.amiri@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aufa.nabil.amiri@gmail.com
--- Comment #9 from aufa.nabil.amiri@gmail.com --- problem persist with wine 3.14, using the newest Line version ( 5.9.2.1763 ).. anyway, why is this bug still have unconfirmed status ?
https://bugs.winehq.org/show_bug.cgi?id=43030
Scott Palmer scott.palmer@protonmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scott.palmer@protonmail.com
--- Comment #10 from Scott Palmer scott.palmer@protonmail.com --- Created attachment 62341 --> https://bugs.winehq.org/attachment.cgi?id=62341 Empty border with no contents
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #11 from Scott Palmer scott.palmer@protonmail.com --- Does anyone know what Microsoft Windows DLL(s) QT DLLs use to draw? I was thinking of replacing those with native versions and seeing if the problem goes away. This may help the devs track down the issue faster.
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #12 from Utente Vino utentevino@20boxme.org --- On my system (Lubuntu 16.04.3 with Wine 3.16) Line 5.10.0.1789 doesn't have this issue anymore. The borders of windows are still thicker than what should be though.
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #13 from 張修銘 cges30901@gmail.com --- I still have this issue on Manjaro. I am using wine 3.16 and LINE 5.10.0.1789.
https://bugs.winehq.org/show_bug.cgi?id=43030
Zachary Murray dremelofdeath@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dremelofdeath@gmail.com
--- Comment #14 from Zachary Murray dremelofdeath@gmail.com --- This is also happening for me, LINE version 5.10.0.1789. I'm using Wine 3.16 in a clean prefix on Xubuntu 16.04 in Xfce4. Wine windows can even draw over themselves.
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #15 from Zachary Murray dremelofdeath@gmail.com --- Created attachment 62425 --> https://bugs.winehq.org/attachment.cgi?id=62425 Issue in LINE 5.10.0.1789 + Wine 3.16
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #16 from Zachary Murray dremelofdeath@gmail.com --- I dug into this bug and figured out a hack to make it render correctly. I'm pretty sure I can turn this into a real patch once I understand the implications of Wine's managed window mode but further investigation is required.
The problem lies in how Wine's X11 driver handles override redirection. LINE creates a separate window exclusively for the border whose X window is of type Dialog and has override redirection enabled. The main window with the actual contents (such as login, QR code, etc.) is in a separate window whose type is Window and has override redirection disabled. Both X windows are root windows with no children. X override redirection causes the border-only window to be drawn over all other windows here.
By forcing the override redirection to always be disabled (attr->override_redirect = False) in the X11 driver -- in get_window_attributes() -- LINE starts rendering correctly and hiding properly when minimized.
That said, I'm not convinced that the problem lies in the X11 driver itself. Typically Wine enables override redirection on an X window that is not a managed window (data->managed is false). It is possible that Wine is improperly setting the border's X window to be unmanaged when it should not be.
I believe changing the window mode from managed to desktop will make LINE work correctly as well, but I haven't tested it yet.
I looked into the history of this code and found that prior to commit dc4fe7735bf60c2bb6981b7c6c7012d276691126, Wine disabled override redirection for all topmost children. That change introduced the managed window check for enabling override redirection. I am planning to investigate if reintroducing similar behavior also fixes the issue.
I noticed one other curious thing about this bug while testing, which is that if you allow the login QR code to expire (which generates a popup dialog saying the QR code is no longer valid) and then minimize LINE, the parent border window is NOT minimized and continues drawing over other windows, even though its contents are transparent. I suspect this is a separate bug and that Wine's handling of LINE's strange drawing behavior is not minimizing all its X windows correctly. However, fixing this bug (improper override redirection) will probably hide that issue.
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #17 from Utente Vino utentevino@20boxme.org --- An update on my previous comment (#12) I experience this bug only when I launch LINE, during normal use this doesn't happen. @Zachary maybe you could ask the forum if they have more info about how wine works?
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.
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #19 from Zachary Murray dremelofdeath@gmail.com --- Created attachment 62577 --> https://bugs.winehq.org/attachment.cgi?id=62577 Issue during normal use with chat window displayed in Wine 3.16
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #20 from Zachary Murray dremelofdeath@gmail.com --- Created attachment 62579 --> https://bugs.winehq.org/attachment.cgi?id=62579 Borders broken even in a virtual desktop, Wine 3.16
I also experience some border strangeness in a virtual desktop. This also reproduces #12's "thick borders" (no shadow transparency) issue by doing this.
https://bugs.winehq.org/show_bug.cgi?id=43030
Jactry Zeng jactry92@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jactry92@gmail.com
--- Comment #21 from Jactry Zeng jactry92@gmail.com --- Hi Zachary, (In reply to Zachary Murray from comment #18)
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.
I tested it on macOS which using mac driver and it can't be reproduced.
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #22 from Zachary Murray dremelofdeath@gmail.com --- (In reply to Jactry Zeng from comment #21)
Hi Zachary, (In reply to Zachary Murray from comment #18)
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.
I tested it on macOS which using mac driver and it can't be reproduced.
Thanks for checking that, Jactry, this is super helpful. Given it doesn't happen in the Mac driver, I'm now convinced this is related to the X11 driver and how it sets override redirection on only the border window.
I saw Alexandre's suggestion in #4 to disallow the window manager to control the windows in winecfg, so I gave that a try. Of course this causes LINE to stay above all other windows when configured this way. I checked the states of both the content window and the border window in this state and both of them have override redirection enabled (expected because this is the standard way to ignore the WM).
Wine should not be overriding redirection on the border window. Fixing that will at least solve the problem for managed mode but probably won't fix the thick borders issue though.
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #23 from Utente Vino utentevino@20boxme.org --- @Zachary I don't remember when but many versions ago the borders were very thin, then they got thicker. hanks for the efforts you are putting!
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #24 from Scott Palmer scott.palmer@protonmail.com --- Has a commit been made to correct this? What is the commit number? Is it available in a daily build?
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #25 from Zachary Murray dremelofdeath@gmail.com --- I haven't made a commit yet. I'm still working on it (have to keep my day job). However, I'm sure there are actually two bugs that are making this happen. The first I fixed, but it by itself only works in a specific unclean prefix I have with a lot of overrides. In a clean prefix, using that fix and a hack I have in the X11 driver makes it work but breaks a lot of other apps and rendering in FVWM.
Given that the unclean prefix with overrides works with only the first fix (and no X11 driver hack), there has to be something somewhere else that's broken. That's what I'm working on right now -- figuring out what is making the unclean prefix work so that I can fix it too.
I'll make a patch/commit when I figure that out and fix the tests I've broken.
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #26 from Scott Palmer scott.palmer@protonmail.com --- Can someone with access please set this to CONFIRMED.
@Zachary You said "However, I'm sure there are actually two bugs that are making this happen". any chance you can link the 2 bugs so all those on this list can follow this bug's progress better?
Please and thank you, Scott
https://bugs.winehq.org/show_bug.cgi?id=43030
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1
--- Comment #27 from Austin English austinenglish@gmail.com --- Confirming
https://bugs.winehq.org/show_bug.cgi?id=43030
p.ridho@yahoo.co.id changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |p.ridho@yahoo.co.id
--- Comment #28 from p.ridho@yahoo.co.id --- Created attachment 63070 --> https://bugs.winehq.org/attachment.cgi?id=63070 Screenshot of bug on i3, LINE is on workspace 10
Screenshot of bug on i3, LINE is on workspace 10 and opened 2 LINE window and the screenshot is from workspace 1. Bug still persist on another DE/WM
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #29 from badflagello badflagello@hotmail.it --- On LINE v5.16.2.XXXX and WINE 4.8 the border stays only if you click outside the program window. If you click on LINE in systray LINE minimizes and borders don't remain.
https://bugs.winehq.org/show_bug.cgi?id=43030
gamer.fikri@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gamer.fikri@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=43030
Ramdhan n0psledbyte@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |n0psledbyte@gmail.com
--- Comment #30 from Ramdhan n0psledbyte@gmail.com --- this issue still exist in wine 5.0 using LINE 5.17
https://bugs.winehq.org/show_bug.cgi?id=43030
Reinhart Previano reinhart_previano@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |reinhart_previano@yahoo.com
--- Comment #31 from Reinhart Previano reinhart_previano@yahoo.com --- In LINE version 6.0.3, the developers have removed that thin, black border. Not what's left is just the window shadow, which is less intrusive than before.
Tested on WINE 5.0, Ubuntu 20.04
https://bugs.winehq.org/show_bug.cgi?id=43030
meowsuke@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |meowsuke@gmail.com
--- Comment #32 from meowsuke@gmail.com --- Issue still exists on Ubuntu 20.04 with Wine 5.0.2 and Line 6.2.2.2293, but I have noticed that it doesn't occur if I click the minimise button instead of alt-tabbing out.
https://bugs.winehq.org/show_bug.cgi?id=43030
axzxc1236 axzxc1236_wine_tracker@protonmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |axzxc1236_wine_tracker@prot | |onmail.com
--- Comment #33 from axzxc1236 axzxc1236_wine_tracker@protonmail.com --- I saw comment #16 (thanks a lot! I couldn't never figure this out myself in 100 years) and decided to create a patch for myself, it does in fact removed black border that was happening when clicking to other non-LINE window.
I use KDE Plasma and didn't see random blank window appearing when restoring from iconify (is iconify a word?), also doesn't see border render incorrectly again. The issue #1 I am seeing is that some border didn't get cleared up when moving LINE window downward, which can usually be cleared by moving LINE window again. (I only ran the patched wine for like half an hour so needs more testing)
The patch below is tested with 6.0-rc1. !!!You should compile/install wine patched with this to a separate location that is not in $path because it was not tested enough!!!
--- a/dlls/winex11.drv/window.c +++ b/dlls/winex11.drv/window.c @@ -345,7 +345,9 @@ static unsigned long get_mwm_decorations( struct x11drv_win_data *data, */ static int get_window_attributes( struct x11drv_win_data *data, XSetWindowAttributes *attr ) { - attr->override_redirect = !data->managed; + //attr->override_redirect = !data->managed; + //patch for issue 43030..... only intended for LINE + attr->override_redirect = 0; attr->colormap = data->whole_colormap ? data->whole_colormap : default_colormap; attr->save_under = ((GetClassLongW( data->hwnd, GCL_STYLE ) & CS_SAVEBITS) != 0); attr->bit_gravity = NorthWestGravity;
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #34 from axzxc1236 axzxc1236_wine_tracker@protonmail.com --- Ignore my last comment (side effects is very annoying), I think I have a better approach (workaround, not fix) to this problem now.
https://gist.github.com/axzxc1236/1d1b737a8b2d5c2a3e2026e4cf9d332a
The above links to a shell script that I am using, it's not without cons but I think it's good enough to share here.
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #35 from Jactry Zeng jactry92@gmail.com --- This bug looks like a duplication of bug 34631 . Does Zhiyi's patch in https://bugs.winehq.org/show_bug.cgi?id=34631#c12 work for Line as well?
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #36 from axzxc1236 axzxc1236_wine_tracker@protonmail.com --- Jactry Zeng I just compiled wine with the patch but the problem isn't fixed.
https://bugs.winehq.org/show_bug.cgi?id=43030
Jactry Zeng jactry92@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |https://desktop.line-scdn.n | |et/win/new/LineInst.exe
https://bugs.winehq.org/show_bug.cgi?id=43030
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net URL|https://desktop.line-scdn.n |https://web.archive.org/web |et/win/new/LineInst.exe |/20190330095509/https://des | |ktop.line-scdn.net/win/new/ | |LineInst.exe
https://bugs.winehq.org/show_bug.cgi?id=43030
Shivelight cawkfranchise@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cawkfranchise@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=43030
yan12125+foss@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |yan12125+foss@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=43030
--- Comment #37 from yan12125+foss@gmail.com --- This is a duplicate of bug 35294.