http://bugs.winehq.org/show_bug.cgi?id=34631
Bug #: 34631 Summary: 163music: shadow of windows is always on the top of desktop Product: Wine Version: 1.7.2 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: jactry92@gmail.com Classification: Unclassified
Created attachment 46149 --> http://bugs.winehq.org/attachment.cgi?id=46149 the log
reproduce follow this: 0. download and install 163music: "下一步(N)" -> "我接受(I)" -> "安装(I)" -> "完成(L)" And it will start up automatically after the installation; 2. There will be a login window, and shadow of it is always on the top.(as picture 1.png) You may need a white background to make it more clear.(as picture 2.png)
This is a software in Chinese and I can't find a version in english. So if you need any help when you trying to reproduce it, please feel free to ping me in #winehackers or email me.
http://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #1 from Jactry Zeng jactry92@gmail.com 2013-09-30 08:29:21 CDT --- Created attachment 46150 --> http://bugs.winehq.org/attachment.cgi?id=46150 the login window
http://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #2 from Jactry Zeng jactry92@gmail.com 2013-09-30 08:29:53 CDT --- Created attachment 46151 --> http://bugs.winehq.org/attachment.cgi?id=46151 the shadow which is always on the top
http://bugs.winehq.org/show_bug.cgi?id=34631
Jactry Zeng jactry92@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://music.163.com/api/pc | |/download/latest
http://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #3 from Jactry Zeng jactry92@gmail.com 2013-09-30 08:52:08 CDT --- Created attachment 46154 --> http://bugs.winehq.org/attachment.cgi?id=46154 login
The main window shadow also can reproduce it.
You may need a account to login it and here is a account for testing: account: winedbg@163.com password: winehq
You can click the last button in the login window (as pciture 3.png) and login it with this account.
http://bugs.winehq.org/show_bug.cgi?id=34631
Jactry Zeng jactry92@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #46150|the login window |picture 1 description| |
http://bugs.winehq.org/show_bug.cgi?id=34631
Jactry Zeng jactry92@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #46151|the shadow which is always |picture 2 description|on the top |
http://bugs.winehq.org/show_bug.cgi?id=34631
Jactry Zeng jactry92@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #46154|login |picture 3 description| |
http://bugs.winehq.org/show_bug.cgi?id=34631
lizhenbo litimetal@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |litimetal@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=34631
Jactry Zeng jactry92@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fracting@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #4 from Jactry Zeng jactry92@gmail.com --- Created attachment 53699 --> https://bugs.winehq.org/attachment.cgi?id=53699 hack for workaround
Here is a hack for it. This bug also impacts WeChat PC. It seems they use a same third party UI library(ANGLE - Almost Native Graphics Layer Engine?).
https://bugs.winehq.org/show_bug.cgi?id=34631
Georgy Yunaev gyunaev@ulduzsoft.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gyunaev@ulduzsoft.com
--- Comment #5 from Georgy Yunaev gyunaev@ulduzsoft.com --- I can confirm this bug is still present and affects WeChat PC.
https://bugs.winehq.org/show_bug.cgi?id=34631
lilydjwg@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lilydjwg@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=34631
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC| |dark.shadow4@web.de
--- Comment #6 from Fabian Maurer dark.shadow4@web.de --- Still affectes WeChat as of wine-4.3. The hack doesn't help. To reproduce:
https://mirrors.ustc.edu.cn/deepin//pool/non-free/d/deepin.com.wechat/deepin...
Extract the deb, then "opt/deepinwine/apps/Deepin-WeChat/files.7z", then run "drive_c/Program Files/Tencent/WeChat/WeChat.exe"
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #7 from Fabian Maurer dark.shadow4@web.de --- Created attachment 63881 --> https://bugs.winehq.org/attachment.cgi?id=63881 Screenshot (See the rectangle on the right, it's from the login window)
https://bugs.winehq.org/show_bug.cgi?id=34631
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|163music: shadow of windows |163music / WeChat: shadow |is always on the top of |of windows is always on the |desktop |top of desktop
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #8 from Fabian Maurer dark.shadow4@web.de --- Same issue(?) affects Radio.fx: https://club.tobit.com/radiofx/download.asp
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #9 from lilydjwg@gmail.com --- With wine 4.16 & 4.19 I don't have this issue with WeChat but with 4.20 it's back. I'll do a bisect later.
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #10 from lilydjwg@gmail.com --- Sorry for the last comment, I came to the wrong bug.
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #11 from lilydjwg@gmail.com --- I find that these gray shadows are actually a window. They are supposed to appear with the main windows but not aware of multiple desktops of X Window and appear on every desktop. With WeChat I also have a small info window noting about new messages 「↟X条新消息 | x」 appear on every desktop when it's shown.
I can use xwininfo to get the id of the shadow window and use xdotool windowunmap wid to make them disappear (but they'll reappear when I minimize and restore the WeChat window).
https://bugs.winehq.org/show_bug.cgi?id=34631
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzhang@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #12 from Zhiyi Zhang zzhang@codeweavers.com --- Created attachment 67509 --> https://bugs.winehq.org/attachment.cgi?id=67509 patch
Could you try this patch? I'm not sure if this breaks other applications.
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #13 from lilydjwg@gmail.com --- The patch doesn't work well for me with wechat. There is no longer shadows shown on every desktop, but there is an unresponsive window covering wechat windows.
I can manually move away the unresponsive window and use the window underneath, but I can't get rid of it. The unresponsive window appears above the login window, the chat window and the right-click menu of the tray icon.
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #14 from Zhiyi Zhang zzhang@codeweavers.com --- (In reply to lilydjwg from comment #13)
The patch doesn't work well for me with wechat. There is no longer shadows shown on every desktop, but there is an unresponsive window covering wechat windows.
I can manually move away the unresponsive window and use the window underneath, but I can't get rid of it. The unresponsive window appears above the login window, the chat window and the right-click menu of the tray icon.
What window manager are you using?
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #15 from lilydjwg@gmail.com --- I'm using Awesome 3.5.9.
https://bugs.winehq.org/show_bug.cgi?id=34631
GuHua renyuneyun@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |renyuneyun@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=34631
Mark mark@doyle.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mark@doyle.ch
https://bugs.winehq.org/show_bug.cgi?id=34631
Pei-Tang Huang tangtheone@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tangtheone@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=34631
Felix Hädicke felixhaedicke@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |felixhaedicke@web.de
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #16 from Fabian Maurer dark.shadow4@web.de --- Also affects LINE (https://desktop.line-scdn.net/win/legacy/win7or8/LineInst.exe)
https://bugs.winehq.org/show_bug.cgi?id=34631
kuletco@qq.com kuletco@qq.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kuletco@qq.com
--- Comment #17 from kuletco@qq.com kuletco@qq.com --- kUbuntu 20.04.3 has the same problem.
https://bugs.winehq.org/show_bug.cgi?id=34631
Jactry Zeng jactry92@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hytzongxuan@gmail.com
--- Comment #18 from Jactry Zeng jactry92@gmail.com --- *** Bug 46915 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=34631
Knecker l4vebs1mx@relay.firefox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |l4vebs1mx@relay.firefox.com
--- Comment #19 from Knecker l4vebs1mx@relay.firefox.com --- I also experience this with PDF X-Change Editor in Arch (Manjaro, running KDE Plasma and Wine latest stable).
https://bugs.winehq.org/show_bug.cgi?id=34631
fhb33435w@postedmail.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fhb33435w@postedmail.net
--- Comment #20 from fhb33435w@postedmail.net --- I also experience this with PDF-Xchange Editor Plus version 9.3 on openSUSE Leap 15.3 KDE Plasma Version: 5.18.6 KDE Frameworks Version: 5.76.0 Qt Version: 5.12.7 Kernel Version: 5.3.18-150300.59.68-default. It's sufficiently annoying that I fall back to an older version of the PDF-Xchange program which doesn't exhibit this characteristic. A trial version of PDF-Xchange can be downloaded from https://www.tracker-software.com/product/downloads in case anyone wants to check for themselves.
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #21 from Knecker l4vebs1mx@relay.firefox.com --- (In reply to fhb33435w from comment #20)
I also experience this with PDF-Xchange Editor Plus version 9.3 on openSUSE Leap 15.3 KDE Plasma Version: 5.18.6 KDE Frameworks Version: 5.76.0 Qt Version: 5.12.7 Kernel Version: 5.3.18-150300.59.68-default. It's sufficiently annoying that I fall back to an older version of the PDF-Xchange program which doesn't exhibit this characteristic. A trial version of PDF-Xchange can be downloaded from https://www.tracker-software.com/product/downloads in case anyone wants to check for themselves.
I found a workaround for this problem: Set the Windows Version to 10 in $ winecfg.
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #22 from fhb33435w@postedmail.net --- (In reply to Knecker from comment #21)
(In reply to fhb33435w from comment #20)
I also experience this with PDF-Xchange Editor Plus version 9.3 on openSUSE Leap 15.3 KDE Plasma Version: 5.18.6 KDE Frameworks Version: 5.76.0 Qt Version: 5.12.7 Kernel Version: 5.3.18-150300.59.68-default. It's sufficiently annoying that I fall back to an older version of the PDF-Xchange program which doesn't exhibit this characteristic. A trial version of PDF-Xchange can be downloaded from https://www.tracker-software.com/product/downloads in case anyone wants to check for themselves.
I found a workaround for this problem: Set the Windows Version to 10 in $ winecfg.
Thanks very much! I would have never thought to try that.
https://bugs.winehq.org/show_bug.cgi?id=34631
jubilantjerry@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jubilantjerry@gmail.com
--- Comment #23 from jubilantjerry@gmail.com --- Drop shadow is still appearing for me, on top of all windows. I run Wine 7.16 Staging, and see the issue for WeChat, DingDing, and their installers. winecfg Windows 10 workaround does not work for me.
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #24 from jubilantjerry@gmail.com --- I've found a workaround in my instance of this bug. If I use an Ubuntu keyboard shortcut to minimize the application window showing the drop shadow problem, then the drop shadow no longer lingers on top of all windows even after the main window is restored.
After starting the application fresh, if I use the minimize button that comes with the application window, the drop shadow is gone. But the drop shadow will come back when the main window is restored. If I use the keyboard shortcut, then the drop shadow never comes back, regardless of how I restore / minimize / resize the same window afterward. New windows created by the same application may still show the drop shadow. Not all windows respond to the Ubuntu shortcut, which is kind of annoying, but having the main window be responsive to that is already a nice improvement.
This leaves me with a couple questions: if the drop shadow is behaving like a window, why doesn't it appear as a separate entry in the dock like other cases when an application has multiple windows, and why does the keyboard shortcut handle this differently from pressing the minimize button?
https://bugs.winehq.org/show_bug.cgi?id=34631
Knecker l4vebs1mx@relay.firefox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|l4vebs1mx@relay.firefox.com |
https://bugs.winehq.org/show_bug.cgi?id=34631
Jactry Zeng jactry92@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |399989567@qq.com
--- Comment #25 from Jactry Zeng jactry92@gmail.com --- *** Bug 53771 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #26 from 399989567@qq.com --- (In reply to jubilantjerry from comment #24)
I've found a workaround in my instance of this bug. If I use an Ubuntu keyboard shortcut to minimize the application window showing the drop shadow problem, then the drop shadow no longer lingers on top of all windows even after the main window is restored.
After starting the application fresh, if I use the minimize button that comes with the application window, the drop shadow is gone. But the drop shadow will come back when the main window is restored. If I use the keyboard shortcut, then the drop shadow never comes back, regardless of how I restore / minimize / resize the same window afterward. New windows created by the same application may still show the drop shadow. Not all windows respond to the Ubuntu shortcut, which is kind of annoying, but having the main window be responsive to that is already a nice improvement.
This leaves me with a couple questions: if the drop shadow is behaving like a window, why doesn't it appear as a separate entry in the dock like other cases when an application has multiple windows, and why does the keyboard shortcut handle this differently from pressing the minimize button?
I'm sure "the drop shadow" is a window,For DingTalk's drop shadow
———————————————
Possible useful information for Window S(which is used to modify the previous window):
APPS:DingTalk
APP_Download_URL:https://dtapp-pub.dingtalk.com/dingtalk-desktop/win_downloader/dingtalk_down...
[ You can reproduce the problem without an account ]
- Function calls for drawing windows:CreateWindowExW -> WIN_CreateWindowEx
- Windows className:DuiShadowWnd
- style: WS_POPUP WS_CLIPSIBLINGS style=84000000
- exstyle: WS_EX_TRANSPARENT WS_EX_TOOLWINDOW WS_EX_LAYERED WS_EX_NOACTIVATE
ex=080800a0
———————————————
so I think it's a window
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #27 from jubilantjerry@gmail.com --- (In reply to 399989567 from comment #26)
I also saw your post on Bug 53771, good investigative work.
I think because of these options, the transparent window doesn't show up on the dock / taskbar? WS_EX_TRANSPARENT WS_EX_TOOLWINDOW WS_EX_LAYERED WS_EX_NOACTIVATE
My guess is that the Ubuntu shortcut minimizes all windows attached to the main one, including tool windows, whereas the minimize button is actually just a normal button on the window that doesn't minimize the transparent part. Perhaps the restore logic doesn't explicitly restore the transparent window because Wechat / QQ / DingTalk expects the transparent window to always be present.
Sven, does your tool show whether windows are truly minimized or not? If so could you check if the transparent window is still there if you minimize DingTalk on Windows?
I noticed that Ubuntu itself also draws drop shadows on windows that have focus. But I verified that the shadow that lingers after minimization the app's custom shadow, not Ubuntu's. For one, Ubuntu only draws the shadow on windows that have focus. Secondly, the shadow looks different. See my attachments:
shadows_1 shows the Ubuntu drop shadow around a Firefox window that has focus vs. a lingering buggy shadow from DingTalk vs. a shadow from a non-minimized Wechat window that is not in focus. The Firefox shadow is lighter.
shadows_2 shows what I see if I give focus to the Wechat window. The Wechat shadow is darker than even the buggy shadow from DingTalk, and there's no shadow around the Firefox window. This means the Wechat window in focus has both the Ubuntu shadow and the transparent window's shadow.
These results mean that the invisible shadow window is not minimized and still rendering the shadow, as expected. What I don't know is what is supposed to happen on real Windows - does the invisible window get minimized too, or does the invisible window stay non-minimized and simply stops rendering the shadow?
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #28 from jubilantjerry@gmail.com --- Created attachment 73256 --> https://bugs.winehq.org/attachment.cgi?id=73256 Comparison of drop shadows of 3 windows
https://bugs.winehq.org/show_bug.cgi?id=34631
jubilantjerry@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #73256|Comparison of drop shadows |shadows_1 description|of 3 windows |
https://bugs.winehq.org/show_bug.cgi?id=34631
jubilantjerry@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #73256|shadows_1 |shadows2 description| | Attachment #73256|shadows1.png |shadows2.png filename| |
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #29 from jubilantjerry@gmail.com --- Created attachment 73257 --> https://bugs.winehq.org/attachment.cgi?id=73257 shadows1
https://bugs.winehq.org/show_bug.cgi?id=34631
jubilantjerry@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #73257|shadows2.png |shadows1.png filename| |
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #30 from 399989567@qq.com --- (In reply to jubilantjerry from comment #27)
My guess is that the Ubuntu shortcut minimizes all windows attached to the main one, including tool windows, whereas the minimize button is actually just a normal button on the window that doesn't minimize the transparent part. Perhaps the restore logic doesn't explicitly restore the transparent window because Wechat / QQ / DingTalk expects the transparent window to always be present.
The system I use is Debian+X11, in wine7.18, in fact when I click the shrink button in the upper right corner of the window, the transparent window will shrink synchronously.
Sven, does your tool show whether windows are truly minimized or not? If so could you check if the transparent window is still there if you minimize DingTalk on Windows?
I think the tool can't do this. The tool is WinSpy.exe you can download on URL:http://www.catch22.net/assets/files/software/WinSpy17.zip
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #31 from Zeb Figura z.figura12@gmail.com --- *** Bug 53772 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #32 from 399989567@qq.com --- (In reply to Zeb Figura from comment #31)
*** Bug 53772 has been marked as a duplicate of this bug. ***
(In reply to jubilantjerry from comment #27)
(In reply to 399989567 from comment #26)
I also saw your post on Bug 53771, good investigative work.
I think because of these options, the transparent window doesn't show up on the dock / taskbar? WS_EX_TRANSPARENT WS_EX_TOOLWINDOW WS_EX_LAYERED WS_EX_NOACTIVATE
My guess is that the Ubuntu shortcut minimizes all windows attached to the main one, including tool windows, whereas the minimize button is actually just a normal button on the window that doesn't minimize the transparent part. Perhaps the restore logic doesn't explicitly restore the transparent window because Wechat / QQ / DingTalk expects the transparent window to always be present.
Sven, does your tool show whether windows are truly minimized or not? If so could you check if the transparent window is still there if you minimize DingTalk on Windows?
I noticed that Ubuntu itself also draws drop shadows on windows that have focus. But I verified that the shadow that lingers after minimization the app's custom shadow, not Ubuntu's. For one, Ubuntu only draws the shadow on windows that have focus. Secondly, the shadow looks different. See my attachments:
shadows_1 shows the Ubuntu drop shadow around a Firefox window that has focus vs. a lingering buggy shadow from DingTalk vs. a shadow from a non-minimized Wechat window that is not in focus. The Firefox shadow is lighter.
shadows_2 shows what I see if I give focus to the Wechat window. The Wechat shadow is darker than even the buggy shadow from DingTalk, and there's no shadow around the Firefox window. This means the Wechat window in focus has both the Ubuntu shadow and the transparent window's shadow.
These results mean that the invisible shadow window is not minimized and still rendering the shadow, as expected. What I don't know is what is supposed to happen on real Windows - does the invisible window get minimized too, or does the invisible window stay non-minimized and simply stops rendering the shadow?
I found that the reason for the problem is that the window is not added to the window manager, do you know which developer should discuss this problem with?
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #33 from 399989567@qq.com --- (In reply to Zeb Figura from comment #31)
*** Bug 53772 has been marked as a duplicate of this bug. ***
I would like to ask what is the reason for judging whether a window is added to the window manager in wine. For example, in the is_window_manger function of winex11.drv, I see that the child window in wine does not need to be added to the window manager, and the full-screen window needs to be added to the window manager.
====================
I would like to ask what is the basis for judging whether a window is added to the window manager? I'm not asking the code logic for the judging in wine, I'm asking why the code be coding like that? If we judging a window need to be add to the window manager,What is the basis we follow?
such as : We know that the child window is managed by its parent window, so there is no need to join the window management.
====================
Because I think a visible POPUP window (WS_VISIBLE) in the screen should be added to the window pipe, but I want to know "the basis for judging whether a window is added to the window pipe", and then judge whether my logic is correct.
If my logic is correct then this bug will be fixed.
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #34 from 399989567@qq.com --- (In reply to 399989567 from comment #33)
(In reply to Zeb Figura from comment #31)
*** Bug 53772 has been marked as a duplicate of this bug. ***
I would like to ask what is the reason for judging whether a window is added to the window manager in wine. For example, in the is_window_manger function of winex11.drv, I see that the child window in wine does not need to be added to the window manager, and the full-screen window needs to be added to the window manager.
====================
I would like to ask what is the basis for judging whether a window is added to the window manager? I'm not asking the code logic for the judging in wine, I'm asking why the code be coding like that? If we judging a window need to be add to the window manager,What is the basis we follow?
such as : We know that the child window is managed by its parent window,
so there is no need to join the window management.
====================
Because I think a visible POPUP window (WS_VISIBLE) in the screen should be added to the window pipe, but I want to know "the basis for judging whether a window is added to the window pipe", and then judge whether my logic is correct.
If my logic is correct then this bug will be fixed.
I refuted myself, adding the shadow window to the window manager can indeed solve the problem, and the shadow window will not be displayed on the top layer, but such modification will cause new problems, so there should be a corresponding reason that wine did not do this in the design. consideration (although I still don't know what kind of consideration)
I will still be here for getting the basis for judging whether a window is added to the window manager.
https://bugs.winehq.org/show_bug.cgi?id=34631
Peet pisit.jee@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pisit.jee@gmail.com
--- Comment #35 from Peet pisit.jee@gmail.com --- In my case i go to wine config > graphics > then uncheck "Allow the window manager to decorate the windows" and it work for me.
https://bugs.winehq.org/show_bug.cgi?id=34631
Clocks doomsdayrs@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |doomsdayrs@gmail.com
--- Comment #36 from Clocks doomsdayrs@gmail.com --- With the Wayland driver enabled, this issue leads to WeChat and similar applications being completely unusable.
With Wine 8.17 I was able to cycle the wine theme via winecfg between light and dark to cause the shadow window to become visible.
As of Wine 8.19 I am no longer able to do the above bypass.
If DingTalk, WeChat, and other shadow-windowed applications are run via wayland, all UI elements are completely inaccessible.
https://bugs.winehq.org/show_bug.cgi?id=34631
Jactry Zeng jactry92@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |winex11.drv
--- Comment #37 from Jactry Zeng jactry92@gmail.com --- (In reply to Clocks from comment #36)
If DingTalk, WeChat, and other shadow-windowed applications are run via wayland, all UI elements are completely inaccessible.
This sounds like an issue of the wayland driver.
https://bugs.winehq.org/show_bug.cgi?id=34631
--- Comment #38 from Clocks doomsdayrs@gmail.com --- (In reply to Jactry Zeng from comment #37)
(In reply to Clocks from comment #36)
If DingTalk, WeChat, and other shadow-windowed applications are run via wayland, all UI elements are completely inaccessible.
This sounds like an issue of the wayland driver.
Hardly, this specifically is an application issue.
These programs expect to be able to shadow a window on Windows. X11 had support for this use case.
Wayland does not support this use case. It is quite impossible for Wayland to ever support this use case, and it likely never will be supported.
Thus the only options are.
1. The developers of the application fix the issue by allowing the shadow to be disabled. 2. Wine to explicitly deny the application the ability to do a shadow.
We have control over the second option. Thus should advocate for the second option. Which is known to solve the issue.
https://bugs.winehq.org/show_bug.cgi?id=34631
yan12125 pq2sx44teeigl7za@chyen.cc changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pq2sx44teeigl7za@chyen.cc