https://bugs.winehq.org/show_bug.cgi?id=54284
Bug ID: 54284
Summary: File dialog opens manually-entered file name on double
click.
Product: Wine
Version: 8.0-rc2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: comdlg32
Assignee: wine-bugs(a)winehq.org
Reporter: ed7-aspire4925(a)hotmail.com
Distribution: ---
In 8.0-rc2, double clicking anywhere in the file view (right pane) will open a
file specified in the "File name:" field.
By file dialog, I meant the one with a tree view on the left.
If that's not part of comdlg32, please correct me.
To reproduce:
0. Install an application that uses such file dialog, like Notepad++,
1. File -> Open (or equivalent),
2. enter anything on the "File name:" field, preferably a non-existent file,
and
3. double click on the empty space in the file view (right pane).
4. Application opens your file path.
This is not breaking, but probably not the intended behavior.
--
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=54238
Bug ID: 54238
Summary: Wine can't map file with exec priv on real CDROM
Product: Wine
Version: 8.0-rc2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: tuxifan(a)posteo.de
Distribution: ---
During Fresh Minder installation, wine attempts to map a file with EXEC
privilege into memory, causing an icon to fail to load. This can be solved by
the user by remounting the cdrom with exec privilege, but Wine should handle
this on its own (for instance by making an internal copy of the file in a place
where EXEC is possible).
--
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=29937
Bug #: 29937
Summary: File selection dialog view shows Favorites when you
click elsewhere
Product: Wine
Version: 1.4-rc1
Platform: x86-64
URL: http://www.winuae.net/files/InstallWinUAE2330.exe
OS/Version: Linux
Status: UNCONFIRMED
Severity: trivial
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: markk(a)clara.co.uk
Classification: Unclassified
There is a small issue with file selection dialogs which some programs use.
When the dialog opens, it shows the files in some directory in the right pane,
and a tree view of the directory hierarchy in the left pane. The tree view
shows Favorites and Desktop (which is expanded to show My Computer, My
Documents, Trash, /).
If you then click on any of the + or - symbols in the tree view, the view in
the right pane jumps to Favorites. For example, click the + next to My Computer
and the view on the right changes to Favorites (which may be empty).
The directory shown in the right pane should probably not change when the user
clicks a + or - symbol in the left pane.
WinUAE is one program which uses that type of file dialog. To show the problem,
download and run the WinUAE installer, check the box to run the program at the
end. When the WinUAE Properties window appears, click "Select image file" to
open a file selection dialog.
--
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=49882
Bug ID: 49882
Summary: Overdrive audio book app will not start. Worked fine
in WINE version 5.0.1
Product: Wine
Version: 5.0.2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: ben.miller.5150(a)gmail.com
Distribution: ---
Created attachment 68225
--> https://bugs.winehq.org/attachment.cgi?id=68225
backtrace.txt produced when Overdrive fails
Overdrive app is no longer working in WINE 5.0.2. It has only stopped working
since upgrading WINE from 5.0.1
--
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=51234
Bug ID: 51234
Summary: user32:clipboard test_ClipboardOwner() has a race
condition with clipboard managers
Product: Wine
Version: 6.8
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
test_ClipboardOwner() has a race condition with clipboard managers that causes
this set of failures:
clipboard.c:404: Test failed: SetClipboardData succeeded
clipboard.c:406: Test failed: wrong error 3735928559
clipboard.c:407: Test failed: SetClipboardData succeeded
Fortunately(?) this failure is pretty rare.
What happens is this:
* test_ClipboardOwner() does this:
OpenClibpoard(NULL)
EmptyClipboard() // take ownership
CloseClipboard()
* Then the clipboard manager starts checking the content of the clipboard:
OpenClipboard(manager_hwnd)
...
* And then the next test_ClipboardOwner() test happens:
SetClipboardData(CF_WAVE, ...)
ok(GetLastError() == ERROR_CLIPBOARD_NOT_OPEN, ...)
ok(!IsClipboardFormatAvailable(CF_WAVE), ...
Because test_ClipboardOwner() opened the clipboard with a NULL windows handle,
EmptyClipboard() used that as the clipboard owner. But when the owner is NULL a
process can place data in the clipboard as long as any process opened it. This
is actually the whole point of the run_process("set_clipboard_data 4") test.
So the problem is that user32:clipboard assumes that no other process is going
to open the clipboard after it called CloseClipboard(). Yet that's precisely
when clipboard manager would receive a WM_CLIPBOARDUPDATE message and open it.
--
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=54055
Bug ID: 54055
Summary: winhttp:winhttp times out in Wine on fg-deb64
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: winhttp
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
Created attachment 73608
--> https://bugs.winehq.org/attachment.cgi?id=73608
winhttp: Set the default DNS resolution timeout to infinite.
winhttp:winhttp started timing out on 2022-11-24 in Wine on fg-deb64:
...
winhttp.c:5215: IEProxy.ProxyBypass=(null)
winhttp:winhttp:0250 done (258) in 120s 1133B
See https://test.winehq.org/data/patterns.html#winhttp:winhttp
As far as can tell the timeout started with the commit below:
commit cbfe940a1eaf5e158de3127b1265462bfbfb70af
Author: Paul Gofman <pgofman(a)codeweavers.com>
Date: Wed Nov 23 15:36:19 2022 -0600
winhttp: Set name resolution timeout in download_script().
I'm not totally sure because the failure is not actually 100% reproducible and
gave some bad results a couple of times. But having it point at this commit
makes sense.
+ WinHttpSetTimeouts( ses, 5000, 60000, 30000, 30000 );
The timeouts disappeared when I changed the resolve timeout from 5000 ms to 0
(no timeout). So... I have a slow DNS setup? That may actually be true since
it's somewhat complicated.
But then the documentation also says that the default DNS resolve timeout is 0.
So maybe the attached patch would make sense?
Also I cannot reproduce the failure anymore. Maybe whatever name we're querying
has been thoroughly cached by all intermediate DNS servers by now. So I should
probably try that again when the DNS cache is cleared.
--
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=53919
Bug ID: 53919
Summary: crypt32:cert - testVerifyRevocation() uses an outdated
certificate
Product: Wine
Version: 7.21
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: crypt32
Assignee: wine-bugs(a)winehq.org
Reporter: jinoh.kang.kr(a)gmail.com
CC: fgouget(a)codeweavers.com, hans(a)meelstraat.net
Distribution: ---
crypt32:cert - testVerifyRevocation() fails in Wine:
cert.c:4191: Test failed: success
cert.c:4192: Test failed: got 00000000
cert.c:4193: Test failed: got 00000000
https://testbot.winehq.org/JobDetails.pl?Key=126125
The failures started on 2022-11-14 and are consistently reproducible since
then. The actual test was introduced on 2022-05-24 in the commit below.
So this is not a regression but instead looks like an outside change that broke
the test.
commit 74832c2177808c6222d44f7e4580de84e0ada8f0
Author: Hans Leidekker <hans(a)codeweavers.com>
AuthorDate: Tue May 24 09:46:22 2022 +0200
crypt32/tests: Add more OCSP revocation tests.
Signed-off-by: Hans Leidekker <hans(a)codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
The commit introduces a variable named ocsp_cert_revoked that contains the
following certificate:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
0d:2e:67:a2:98:85:3b:9a:54:52:e3:a2:85:a4:57:2f
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = DigiCert Inc, CN = RapidSSL TLS DV RSA Mixed SHA256
2020 CA-1
Validity
Not Before: Oct 27 00:00:00 2021 GMT
Not After : Oct 27 23:59:59 2022 GMT
Subject: CN = revoked.badssl.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b0:76:2d:55:66:dc:72:8a:a0:9e:85:92:38:7f:
5b:e1:93:8d:ad:06:c8:ad:e9:89:b4:ef:1e:77:5b:
33:45:16:60:7d:33:38:68:04:d7:c9:83:42:83:d9:
30:4b:54:49:14:ca:ed:be:0c:76:ba:5f:a6:5c:33:
78:3f:39:f2:49:a8:88:32:ee:53:21:14:d3:aa:5c:
58:3c:39:cc:f7:80:b1:27:1f:54:79:7b:6c:8b:ff:
41:aa:39:24:95:5f:71:bc:49:bf:39:3b:a5:d5:e1:
a5:de:1d:40:81:25:dc:8a:47:82:fe:cd:7c:4b:2c:
04:bb:d3:27:56:51:a0:61:f2:d2:cb:55:08:25:2a:
85:db:2c:06:8d:0d:61:c2:5b:3e:9b:46:dc:58:ff:
13:27:be:0a:44:1e:68:fe:e1:f6:b7:de:9f:8e:6c:
c4:b5:19:fa:d7:d3:4f:55:a8:61:79:db:61:2f:6a:
9c:2c:f1:c4:81:bb:9e:d2:02:05:ba:9c:14:a0:f9:
f3:54:79:7d:69:d9:ba:66:1c:87:95:41:50:0e:f9:
5e:e1:b7:bd:f5:31:24:c5:21:21:03:8a:cf:6d:78:
58:de:d9:30:7d:03:42:52:d6:b0:1b:b9:c9:54:1b:
5a:e8:c8:53:f0:ac:2b:82:10:27:a6:a9:70:25:ae:
f8:a7
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
A4:8D:E5:BE:7C:79:E4:70:23:6D:2E:29:34:AD:23:58:DC:F5:31:7F
X509v3 Subject Key Identifier:
B0:C8:CE:20:B2:78:CC:1D:23:EF:F0:FE:D6:0E:29:4B:AC:15:72:3C
X509v3 Subject Alternative Name:
DNS:revoked.badssl.com
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl3.digicert.com/RapidSSLTLSDVRSAMixedSHA2562020CA-1.crl
Full Name:
URI:http://crl4.digicert.com/RapidSSLTLSDVRSAMixedSHA2562020CA-1.crl
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
CPS: http://www.digicert.com/CPS
Authority Information Access:
OCSP - URI:http://ocsp.digicert.com
CA Issuers -
URI:http://cacerts.digicert.com/RapidSSLTLSDVRSAMixedSHA2562020CA-1.crt
X509v3 Basic Constraints:
CA:FALSE
(snip)
The time of first failure is past the expiry date of the certificate above.
It appears that the OCSP provider has retracted the certificate entry in
question, which is no longer necessary.
--
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=48911
Bug ID: 48911
Summary: Check for compilation warnings
Product: Wine-Testbot
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
Compiling Wine with -Werror is troublesome because it applies blindly to both
wine-devel patches and patches submitted manually via the website. The sole
purpose of the latter is often to just clarify some point for the development
of another patch and are not meant to be submitted. Thus failing on warnings
just makes running these quick tests more cumbersome.
So the best way forward would be for the TestBot to identify and report
warnings but not fail the compilation and abort the tests when they occur.
So:
1. The builds should happen without -Werror.
2. GetLogLineCategory() should identify the warnings and add them to LogInfo
but distinguish them from errors (replace IsNew with a Category field?).
3. Compare task.log to the reference build log to distinguish new warnings from
old ones. This is necessary in case the compiler used by the TestBot produces
warnings on the unpatched Wine tree. It will require storing the build logs in
latest/ just like the TestBot already does for the reference WineTest reports.
4. LogInfo's will need to keep track of the number of new warnings which really
means renaming the 'NewCount' field to avoid confusion.
5. The warnings should be saved in the errors files. The new line types could
be 'w' and 'W' for old and new warnings respectively (then it would make sense
to use e and E for errors).
6. This will let the WineRun*() scripts know about both warnings and errors.
They can then decide what to do depending on the type of job and whether the
warnings are new or not.
- Old warnings would always be ignored.
- If a build task has new warnings, instead of marking it as 'badbuild' it
could be marked as 'completed' as usual but with a non-zero number of failures.
This would probably allow running the tests on Windows but the patch would
still be considered bad since the job would end up with a non-zero number of
failures.
- For Wine tasks the number of warnings would be added to the Failures field
for the same overall result.
- So in both cases the non-zero number of failures would only impact
wine-devel patches.
7. The JobDetails page should show the warnings in summary mode and highlight
them in the full build log. That would make it easy for developers to see the
warnings on web-submitted jobs, and thus fix them before submitting the patch
to wine-devel.
--
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=43653
Bug ID: 43653
Summary: Waves Central: install vst plugins issue
Product: Wine
Version: 2.16
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: viking991(a)gmx.de
Distribution: ---
Created attachment 59080
--> https://bugs.winehq.org/attachment.cgi?id=59080
waves central error message
Hi!
Waves Central (license manager / installer from waves.com) does not install vst
plugins in Wine.
installation aborts with this message box, also see attachment
###
Sorry
An error has occurred during installation
Please follow the steps in this troubleshooter
###
- System:
winehq-staging 2.16
debian stretch
- Steps to re-produce:
1) Download Waves Central installer
http://www.waves.com/downloads/central
Direct download link:
http://www.waves.com/dlrdr?id=central-win
Tested Waves Central Version: V1.3.3.4
sha1sum Install_Waves_Central.exe
0f90b9333855a8713e3f9ced767369364a46aa33 Install_Waves_Central.exe
2) Run Installer
wine64 Install_Waves_Central.exe
3) Run Waves Central
wine64 Waves\ Central.exe
4) Log in
unfortunately this needs an account with waves.com:
-> Log in -> create account -> web browser opens to create account
user user/pass in Waves Central to log in.
5) install any VST:
-> install products
-> install from online
-> choose products to install -> All Waves products
-> select any product, for example H-Reverb Hybrid Reverb 9
-> click install, message box as attached appears.
also check bug 43648
Thanks!
--
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=42588
Bug ID: 42588
Summary: Vietcong - graphics glitches since Wine 2.1
Product: Wine
Version: 2.1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: havran.jan(a)email.cz
Distribution: ArchLinux
Created attachment 57517
--> https://bugs.winehq.org/attachment.cgi?id=57517
Vietcong - terminal log
In version 2.1 was introduced new bug that causes graphical glitches like
flickering soldiers. I can confirm this bug in wine versions 2.1, 2.2 and 2.3.
In versions 2.0 and below it worked probably fine - this bug is not 100%
reproducible - sometimes soldiers are flickering and glitches are shown very
often, sometimes just for few milisecond, but i am pretty sure that this was
introduced in version 2.1
Tested on Intel and AMD GPUs, Vietcong 1.60 with VCStarter 1.7 Beta
--
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.