http://bugs.winehq.org/show_bug.cgi?id=27502
Summary: app freezes when WM_KILLFOCUS creates modal dialog
Product: Wine
Version: unspecified
Platform: All
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: user32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: efrias(a)syncad.com
Created an attachment (id=35159)
--> (http://bugs.winehq.org/attachment.cgi?id=35159)
simple example which produces the error
When a program brings up a modal dialog box in response to a WM_KILLFOCUS
message, the program will freeze. I've attached a simple test case, all
boilerplate except for:
case WM_KILLFOCUS:
MessageBox(hWnd, _T("Killing Focus"), _T("Note"), MB_OK);
in the main event loop. If you run the program and then give focus to another
application, the messagebox will pop up and then the program will become
unresponsive.
What is happening is:
- x11drv gets a FocusOut event and calls the event handler, which ends up
SendMessage-ing a WM_KILLFOCUS to the program.
- The programs's code creates a modal dialog like the MessageBox above, and
enters the dialog's event loop, which winds up calling GetMessage which calls
MsgWaitForMultipleObjectsEx to get more X11 events.
- X11DRV_MsgWaitForMultipleObjectsEx executes this:
if (data->current_event) mask = 0; /* don't process nested events
*/
where data->current_event is true since we're still handling the FocusOut
event. Since we're not processing nested events, we'll never be able to
process the usual events like keys or mouse events which could exit this nested
event loop.
This type of error occurs in a few places in our application, where a
WM_KILLFOCUS message to an edit box triggers some input validation and displays
an error on failure. This works correctly in the normal case, where the user
tabs out or clicks on another control in the dialog box containing the edit
control -- since everything stays in the same top-level window, there is no
FocusOut event from X11 and the WM_KILLFOCUS is generated internally by wine in
response to, say, a KeyEvent. I think these key or mouse events are just
posted to the windows message queue, and the X11 event handler has already
exited by the time the application gets around to processing the ensuing
WM_KILLFOCUS. But in the case where focus is lost by clicking outside the
dialog containing the edit control, the WM_KILLFOCUS is generated by the
FocusOut handler which is still executing, and we lock up.
I suspect this is related to bug 11595 "Notepad++ freezes if native application
changes a file it has open (dogfood)". My guess is in that case, a FocusIn
event triggers something like a WM_ACTIVATE, in which notepad++ notices a file
is changed and displays a messagebox asking if you want to reload. Since wine
is still processing the FocusIn event, the modal message loop's call to
MsgWaitForMultipleObjectsEx will never process any useful events because it's a
nested event. Our application's built-in text editor has this same problem.
I don't understand the event handling code well enough to propose a solution.
As a test, I allowed nested event processing and it solved the problem without
introducing any obvious errors, but I'm sure that check was in there for a
reason. It's probably better to keep the application code from being executed
from inside the event handler, if that's possible.
Note: this bug was also posted as a message to wine-devel here:
http://www.winehq.org/pipermail/wine-devel/2011-June/090652.html
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.
https://bugs.winehq.org/show_bug.cgi?id=50444
Bug ID: 50444
Summary: Text not shown/drawn or hidden starting in Wine 5.18
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: support(a)htmlvalidator.com
Distribution: ---
Created attachment 69057
--> https://bugs.winehq.org/attachment.cgi?id=69057
The validation pane (the left-side wide window at screen bottom) as displayed
when running CSS HTML Validator under Wine 3 through Wine 5.17.
POSTING this bug report from a CSS HTML Validator user that uses and test CSS
HTML Validator under Wine.
Going back to at least Wine 3, the CSS HTML Validator validation pane has
always displayed correctly until Wine 5.18, when the upgrade from Wine 5.17 to
Wine 5.18 resulted in the validation pane always displaying blank. The
validation pane is located at the bottom of the full CSS HTML Validator window.
See the attached screenshots, I cropped out most of the upper part of the full
CSS HTML Validator window.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=50442
Bug ID: 50442
Summary: WW2 Online: Fractional scaling causes mouse clicks not
registering
Product: Wine
Version: 6.0-rc4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: ilgaz(a)fastmail.fm
Distribution: ---
Created attachment 69054
--> https://bugs.winehq.org/attachment.cgi?id=69054
output of console
I have openSUSE Tumbleweed here with wine-staging installed and "full wayland"
enabled. I have scaled my 1080p monitor using KDE's scaling to 120% and it
displays 1600x900 in resolution screen.
ww2 online launches fine and when I click "OK" button on a dialogue represented
at startup, nothing happens.
When I disable scaling and use raw 1080p resolution, everything works fine.
Game can be downloaded/played free/ required no "winetricks" whatsoever until
today.
https://www.wwiionline.com/
--
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.
http://bugs.winehq.org/show_bug.cgi?id=32058
Bug #: 32058
Summary: Guild Wars 2 launcher freezes/hangs (unable to launch
game)
Product: Wine
Version: 1.5.15
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: x.egam.wodahs.x(a)gmail.com
CC: julliard(a)winehq.org
Classification: Unclassified
Once I updated wine to version 1.5.15, the Guild Wars 2 launcher can no longer
launch the game because it just freezes/hangs. This was not an issue in 1.5.14,
and in order to run the game for now I'm using wine 1.5.14 compiled from
source.
In wine 1.5.14, the launcher is black (can't see UI at all, but it's still
functional) unless using the -dx9single flag. Using -dx9single, the background
is black instead of transparent but the UI inside is properly rendered. This
information is important because, before submitting this bug report, I
performed two separate git bisects between 1.5.14 and 1.5.15: one without any
command-line parameters, and one using -dx9single.
Technical details follow:
=======================================================================
1) git bisect for running the game without any parameters:
In the last good commit (8dcbeff760115834656f3f1fc85922e3a9af14d0), the
launcher is still black but it still works. You cannot see the UI but by
blindly logging in, the game does launch. In the first bad commit
(f12c1c6630f0bf842dde9af10da4ab188ff16e94), the behavior is different from the
wine 1.5.15 release and the other commits tested: here, instead of locking up,
the window just disappears. It's still there, but I guess it's fully
transparent. Because this leaves us even more "blind", I considered this "bad"
in the git bisect, yielding the following result:
---
f12c1c6630f0bf842dde9af10da4ab188ff16e94 is the first bad commit
commit f12c1c6630f0bf842dde9af10da4ab188ff16e94
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Wed Sep 26 13:12:17 2012 +0200
winex11: Switch to an ARGB visual for layered windows with per-pixel alpha.
:040000 040000 e9933c28f3e50c52d2cee37a43b06a2f5cb5a497
3870099a31a68a69cd7c022857794700c2343aa9 M dlls
---
If, however, we consider f12c1c6630f0bf842dde9af10da4ab188ff16e94 "good" in the
git bisect, we get:
---
d8247efd5ecb8c4604624eb2bbf47e194ce59e7e is the first bad commit
commit d8247efd5ecb8c4604624eb2bbf47e194ce59e7e
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Thu Sep 27 20:47:08 2012 +0200
winex11: Take the alpha channel into account to compute the region of
layered windows.
:040000 040000 3870099a31a68a69cd7c022857794700c2343aa9
d9ec62b63405f910db90b095145a7910cc124eef M dlls
---
In this case, the launcher does indeed lock up in the first bad commit
(d8247efd5ecb8c4604624eb2bbf47e194ce59e7e).
2) git bisect for running the game using -dx9single:
Using the -dx9single flag, we seem to be able to get to a later commit before
it stops working (but does not work in the 1.5.15 release). In the last good
commit (dbff4f422c943a837f0098e921f831eb4a94ac11), everything seems to be fine
(when using the -dx9single flag) and even the transparency seems to be working.
However, in the first bad commit (6f3b097a203d9ca248732cb45eed462599ca3af1),
things start to lock up. This yields the following git bisect result:
---
6f3b097a203d9ca248732cb45eed462599ca3af1 is the first bad commit
commit 6f3b097a203d9ca248732cb45eed462599ca3af1
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Wed Oct 3 00:09:01 2012 +0200
winex11: Fix a typo in the surface region computation with an alpha
channel.
:040000 040000 fa11ac3c80763b81911ba999d8302029d2c6d147
566c9c06b11f8785c870a1e09ec53d42e13d1524 M dlls
---
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.
https://bugs.winehq.org/show_bug.cgi?id=38166
Bug ID: 38166
Summary: Heroes of Might and Magic 5 slowly on some maps.
Product: Wine
Version: 1.7.37
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: galdralag(a)bk.ru
Distribution: ---
On some maps especially when many green trees game works very slowly.
This happens on all versions of nvidia driver AFTER 331.89.
331.89 it is last version when game works on maximum video settings.
May be this is bug of nvidia driver (not wine) but I can't test this.
I tested 2 videocards nvidia 760M and 650 ti.
This can be reproduced on ArchLinux, Fedora, OpenSuse and Kubuntu.
If you have problems with reproducing I can attach some maps where it can be
reprocuced
--
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.
https://bugs.winehq.org/show_bug.cgi?id=50304
Bug ID: 50304
Summary: Control-C exits winedbg instead of stopping the
inferior
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winedbg
Assignee: wine-bugs(a)winehq.org
Reporter: joachim.priesner.bugs(a)web.de
CC: jacek(a)codeweavers.com
Regression SHA1: 633b244b1ae7928cafbfd25ef338e4918aac0d74
Distribution: ---
Created attachment 68875
--> https://bugs.winehq.org/attachment.cgi?id=68875
+winedbg log of hang behavior
To reproduce:
- run wine winedbg program.exe
- press "c <Enter>" to run the program
- press Control-C
Expected: The program is stopped and I am back at the winedbg prompt.
Actual:
The behavior matched the expected one until the following commit:
commit 54e117018cd4cc58c258da92686bfad13946bde2
Author: Jacek Caban <jacek(a)codeweavers.com>
Date: Mon Sep 21 17:07:29 2020 +0200
kernelbase: Use conhost to handle Unix consoles.
Starting at this commit, pressing Control-C would cause winedbg to hang (needed
to "kill -9" it).
The behavior changed again in the following commit:
commit 633b244b1ae7928cafbfd25ef338e4918aac0d74
Author: Jacek Caban <jacek(a)codeweavers.com>
Date: Tue Oct 13 16:27:38 2020 +0200
kernel32: Always use conhost for ReadConsoleW.
Starting at this commit, and until the current master, pressing Control-C
causes winedbg to immediately exit.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=49356
Bug ID: 49356
Summary: failed to load while trying to run game
Product: Wine
Version: 1.8.6
Hardware: x86
OS: Mac OS X
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: ivan_kalis(a)hotmail.com
Created attachment 67401
--> https://bugs.winehq.org/attachment.cgi?id=67401
backtrace i was given when it crashed
i ran the game and it seemed to work until i went to the launcher of the game
which i assume was the windows launcher and it crashed right afterwards with
this message given to me
--
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.
https://bugs.winehq.org/show_bug.cgi?id=50420
Bug ID: 50420
Summary: Divinity: Original Sin - Enhanced Edition crashes on
startup
Product: Wine
Version: 5.11
Hardware: x86-64
URL: https://store.steampowered.com/app/373420/Divinity_Ori
ginal_Sin__Enhanced_Edition/
OS: Linux
Status: NEW
Keywords: regression
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: gyebro69(a)gmail.com
CC: julliard(a)winehq.org
Regression SHA1: df5e4764870e8ad1d8b206cb3475a073bc034e48
Distribution: ArchLinux
Created attachment 69038
--> https://bugs.winehq.org/attachment.cgi?id=69038
terminal output
The game shows a black screen then it crashes (just before the developer logo
would show up).
Reproduced with the GOG and the Steam version.
According to my testing the last working Wine version was 5.10.
The commit when the problem appeared:
df5e4764870e8ad1d8b206cb3475a073bc034e48
ntdll: Move the current directory initialization to the Unix library.
Still present in wine-6.0-rc4-6-gff09f14867e.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=44243
Bug ID: 44243
Summary: Spire and Serum paints very slowly
Product: Wine
Version: 3.0-rc3
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: bique.alexandre(a)gmail.com
Distribution: ---
Hi,
The following programs take a lot of time to render the UI:
https://www.reveal-sound.com/https://www.xferrecords.com/products/serum
A few versions before the UI was just black, and recently it started to paint
correctly, so it must be that you have add new painting/rendering api recently.
Yet the painting performance is really slow, so it would be great if you guys
could have a look and optimize it a bit? Maybe it is an easy thing to do?
Many thanks for your work guys!
To reproduce it you can install a plugin host like reaper:
https://www.reaper.fm/ and then install the vst plugins and try them with
reaper.
Regards,
Alexandre
--
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.
http://bugs.winehq.org/show_bug.cgi?id=21987
Summary: Acrobat 7 tryout complains: This Postscript Driver or
Windows Platform (Win9x/Me) not supported
Product: Wine
Version: 1.1.40
Platform: x86
URL: http://www.adobe.com/products/acrobatpro/tryreg.html
OS/Version: Linux
Status: NEW
Keywords: download
Severity: enhancement
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: jeffz(a)jeffz.name
When installing the Acrobat 7 trial AcTR7EFG.exe, the installer produces a
dialog:
Devmode
This Postscript Driver or Windows Platform (Win9x/Me) not supported
It doesn't prevent the installer from progressing, but the same thing doesn't
happen on Vista.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.