October 2020 - Wine-Bugs - list.winehq.org

[Bug 2155] Failure of SetFocus, SetActiveWindow and SetForegroundWindow

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=2155 --- Comment #27 from Rémi Bernon <rbernon(a)codeweavers.com> --- Created attachment 68358 --> https://bugs.winehq.org/attachment.cgi?id=68358 Rebased user32-rawinput-mouse series -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 8, 2020

[Bug 2155] Failure of SetFocus, SetActiveWindow and SetForegroundWindow

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=2155 --- Comment #26 from Rémi Bernon <rbernon(a)codeweavers.com> --- Created attachment 68357 --> https://bugs.winehq.org/attachment.cgi?id=68357 Rebased user32-rawinput-hid series -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 8, 2020

[Bug 2155] Failure of SetFocus, SetActiveWindow and SetForegroundWindow

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=2155 Rémi Bernon <rbernon(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon(a)codeweavers.com --- Comment #25 from Rémi Bernon <rbernon(a)codeweavers.com> --- Created attachment 68356 --> https://bugs.winehq.org/attachment.cgi?id=68356 Patch series addressing several focus inconsistencies. I spent some time digging into focus issues lately and I believe this issue has several root causes. First of all of course, Wine currently doesn't implement any mechanism to activate other windows on the X11 side. This is implemented by the staged patch, but I believe it can then trigger other focus problems that Wine suffers from. With or without the patch, the root issues are: 1) I believe there's a race condition in the SetForegroundWindow / SetActiveWindow implementation. When multiple threads are involved, SetActiveWindow requests from other threads are only applied when the thread checks its messages, possibly overwriting changes that were done by the thread itself. 2) The asynchronous nature of the focus handling code: Wine applies the Win32 focus state changes immediately, but processes -- and applies -- the results of the X11 activation requests only later, during window message processing. 3) Windows allows hidden windows to be focused and foreground, X11 doesn't allow unmapped windows to be. This is a fundamental difference and it is pretty hard to solve, we currently implement hidden windows as unmapped X11 windows, as it is probably the only way to have truly invisible windows, but it makes it impossible to keep the X11 state consistent in that case. The solutions are either to map hidden windows, using some other mechanism to hide them as much as possible, bottom-most attribute being perhaps the least brittle. Or, as a possible mitigation, force change X11 focus when hidden window is supposed to be focused, so that X11 will send focus change events when it changes back to another window. 4) SetForegroundWindow is not supposed to always succeed, although Wine always pretend it does. The _NET_ACTIVE_WINDOW request also not always succeed, but as we can't wait for its possible result, it is hard to return a reliable success status. This is especially the case with the staged patch, that sends activation requests to be applied later, but it is also the case with user focus changes. Having the X11 events processed and applied only when message processing can trigger a race condition where X11 related focus changes will overwrite the already executed Win32 focus changes, possibly ending up in an inconsistent state. Also, because of 1), when focus events come on several threads, SetActiveWindow messages coming from other threads may be applied at the same as the X11 events are processed and applied, making things even more inconsistent. The attached patch series should help fixing these issues. First of all, it fixes the incorrect message processing order in 1). Then it should try to make 2) work better by tracking X11 focus globally in explorer.exe, so that we don't rely on application processing their messages anymore, and by discarding old SetForegroundWindow requests based on their timestamp. Last, it also implements a similar feature as the staged _NET_ACTIVE_WINDOW patch to send X11 activation requests, but it adds a mitigation for 3) and 4), where SetForegroundWindow returns failure if X11 focus is not on another Wine window, and where SetActiveWindow forcefully unsets X11 focus when hidden window is activated. It is still not completely matching Windows behavior, as SetForegroundWindow should probably return FALSE in more cases, but the details are a little bit more complicated and it may also break some currently working cases. I'm currently trying to upstream the first patches, but the way internal messages gets discarded needed some discussion. The whole series also could benefit from more extensive testing. This is also probably going to conflict with the rawinput patch series, as there are changes in the XInput2 code to get Focus messages with timestamps if possible. I'll attach rebased versions next in the eventuality this goes into staging. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 8, 2020

[Bug 48507] osu! icons in the setting and music player are not being rendered

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48507 --- Comment #7 from Nguyễn Chính Hữu <huupoke12(a)gmail.com> --- By tracing gdiplus with WINEDEBUG, it seems that osu! is using Font Awesome (I think it's Font Awesome 4) to display the icons. The version 4 make use of Unicode private use area to store the glyphs (https://fontawesome.com/v4.7.0/cheatsheet/) So I have tried downloading Font Awesome (4.7.0), changed its name to Tahoma and placed it in Linux's font directory (in order to make the in-game chat use Font Awesome). Then I have copied the characters from the above page and pasted them into the in-game chat, they does not show up (just invisible, no tofu, no character space) but they still take up "backspace" keys to delete (which means if I pasted an icon after a normal character and press "backspace" to delete, it delete the icon first (even invisible), then the normal character. But when I tested in Wine Notepad and Notepad++, they shown up normally. So I guess it's maybe gdiplus doesn't handle that Unicode range properly, or maybe something related to reading the font metrics (such as displaying glyphs at extremely small size so they're just invisible), or something else. By the way, in the #6 comment, it's not "fixed". It happened because the game now doesn't use its custom font (Aller) to display the UI anymore, instead it use Tahoma, and Tahoma have those characters so those characters are displayed. Reverting the file `gdiplus/font.c` to its Wine 5.0 version make it behaves like before, so I would call that a regression. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 8, 2020

[Bug 49964] 32-bit dxdiag doesn't support '/64bit' command line switch (launch 64-bit dxdiag)

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49964 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://redirect.wargaming. | |net/WGC/Wargaming_Game_Cent | |er_Install_EU.exe Keywords| |download -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 8, 2020

[Bug 49964] New: 32-bit dxdiag doesn't support '/64bit' command line switch (launch 64-bit dxdiag)

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49964 Bug ID: 49964 Summary: 32-bit dxdiag doesn't support '/64bit' command line switch (launch 64-bit dxdiag) Product: Wine Version: 5.18 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: programs Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, as it says. Encountered with some Wargaming titles in 64-bit WINEPREFIX. It causes a message box to be shown which stays behind the main game window. Not harmful but still worth to get rid of. --- snip --- $ pwd /home/focht/wine-games/wineprefix64-wargaming/drive_c/ProgramData/Wargaming.net/GameCenter $ WINEDEBUG=+process,+msgbox wine ./wgc.exe --disable-gpu >>log.txt 2>&1 ... 03c0:trace:process:CreateProcessInternalW app (null) cmdline L"dxdiag /whql:off /64bit /t C:\\users\\focht\\Temp\\dxdiag_cat_852.txt.tmp" ... 03c0:trace:process:NtCreateUserProcess L"\\??\\C:\\windows\\system32\\dxdiag.exe" image L"C:\\windows\\system32\\dxdiag.exe" cmdline L"dxdiag /whql:off /64bit /t C:\\users\\focht\\Temp\\dxdiag_cat_852.txt.tmp" parent (nil) ... 03c0:trace:process:NtCreateUserProcess L"\\??\\C:\\windows\\system32\\dxdiag.exe" pid 03cc tid 03d0 handles 0xf8/0xfc 03c0:trace:process:CreateProcessInternalW started process pid 03cc tid 03d0 ... 03d0:trace:msgbox:MSGBOX_OnInit L"Usage: dxdiag [/whql:off | /whql:on] [/t filename | /x filename]" --- snip --- Wine source: https://source.winehq.org/git/wine.git/blob/5d5102f8498413f4b7e11f7da0509e7… NOTE: https://stackoverflow.com/questions/28189656/getting-output-from-dxdiag-in-… --- quote --- DxDiag is quite cranky on a 64-bit OS. The 32-bit version and the 64-bit version accept different command line switches and it doesn't give a peep when you use the wrong one. The /x option simply does not work when you try to use the /64bit option on the 32-bit version. And the 64-bit version does not accept /64bit. You'll have to start the 64-bit version explicitly when you run on a 64-bit OS and your program runs in 32-bit mode. --- quote --- The '64bit' command line switch is simply ignored by the 64-bit executable and not listed in the command line help. $ wine --version wine-5.18-303-g5d5102f8498 Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 8, 2020

[Bug 49963] MobaXTerm 20.3: cannot start a local terminal

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49963 --- Comment #1 from ImperatorS79 <fevrier.simon(a)gmail.com> --- Created attachment 68355 --> https://bugs.winehq.org/attachment.cgi?id=68355 Log MobaXterm 20.3 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 8, 2020

[Bug 49963] New: MobaXTerm 20.3: cannot start a local terminal

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49963 Bug ID: 49963 Summary: MobaXTerm 20.3: cannot start a local terminal Product: Wine Version: 5.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: fevrier.simon(a)gmail.com Distribution: --- Created attachment 68354 --> https://bugs.winehq.org/attachment.cgi?id=68354 Backtrace MobaXterm 20.3 Using MobaXTerm from here -> https://download.mobatek.net/2032020060430358/MobaXterm_Installer_v20.3.zip Using Wine 5.18 on Ubuntu 20.04 using winehq ubuntu ppa. When clicking on "Start local terminal", what assume to be the terminal exe cygtermd.exe crashes. Log and backtrace in attachment. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 8, 2020

[Bug 49962] New: Playground Sessions won't start up: (adobe air?)

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49962 Bug ID: 49962 Summary: Playground Sessions won't start up: (adobe air?) Product: Wine Version: 5.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: a.solernou(a)gmail.com Distribution: --- Created attachment 68353 --> https://bugs.winehq.org/attachment.cgi?id=68353 Traceback of the crash when launching Playground Sessions. Playground Sessions, which can be downloaded here: https://www.playgroundsessions.com/windows https://www.playgroundsessions.com/support/downloads and for which there is one single version: 1fe0616991590187f2760d3d948a027e5834b486 Playground.msi won't launch but immediately crash, and reading the backtrace it seems related to Adobe AIR. I have spent a reasonable amount of time googling for related crashes, but haven't been able to find the right solution. I am using Manjaro 64bit (is there a 32bit version?) here, the latest Wine version to my knowledge 5.18, everything else looks good. This problem did not happen in a previous Wine version. Indeed, in another machine with Ubuntu 20.04, running wine 3.0.3 used to be fine, until recently another bug that made it unusable too. Trying to roll back, and compiling myself Wine 3.0.2, the latest reported working version: https://appdb.winehq.org/objectManager.php?sClass=application&iId=19053 did not do the trick for me either, though again this still a third issue. Anyway, this is all to say that I've done my best to have this software running, without success. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 8, 2020

[Bug 49953] LOOT (Load Order Optimization Tool) crashes at launch

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49953 Anya <maniikarabera(a)protonmail.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maniikarabera(a)protonmail.ch -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 8, 2020