August 2026 - Wine-Bugs - list.winehq.org

[Bug 59082] New: RtlLeaveCriticalSection section spam wizard101.
by WineHQ Bugzilla Aug. 15, 2026

Aug. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59082 Bug ID: 59082 Summary: RtlLeaveCriticalSection section spam wizard101. Product: Wine Version: 10.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: cramea(a)proton.me Distribution: ArchLinux Created attachment 79869 --> http://bugs.winehq.org/attachment.cgi?id=79869 Video showing the issue. Everything you do in Wizard101 spams the RtlLeaveCriticalSection error, and everything in the game takes way longer to load than in native Windows. It also affects loading screens and in-world asset loading. The culprit definitely has to be whatever is causing this RtlLeaveCriticalSection error to be spammed. -- 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.

2 14

[Bug 60174] New: Text in BackPacker game main menu is in the wrong place and upside down
by WineHQ Bugzilla Aug. 15, 2026

Aug. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=60174 Bug ID: 60174 Summary: Text in BackPacker game main menu is in the wrong place and upside down Product: Wine Version: 8.9 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs(a)list.winehq.org Reporter: alexhenrie24(a)gmail.com Target Milestone: --- Distribution: --- The game BackPacker has been through a lot on Wine: The main menu rendered correctly on Wine 8.8. After <https://gitlab.winehq.org/wine/wine/-/commit/3b01fb113fc9b21ebed63f25ff7b80…>, the text on the buttons became too faint to read. After <https://gitlab.winehq.org/wine/wine/-/commit/b3bec339d7851b14abf6f6ca341731…>, the game failed to start with the error "Not enough memory to run BACKPACK.EXE." After <https://gitlab.winehq.org/wine/wine/-/commit/7292edaf55bd18a83b4067e60e52bb…>, the game starts and the text is the right color but in the wrong place and upside down. $ sha256sum Backpacker-1995-English.iso e42377a1e608e66f4926d5f91ce773cd02a74dc05a718a7f843ee19a2c9b49b8 -- 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.

1 8

[Bug 60171] New: A click that falls through a native-surface-less active top-level window incorrectly deactivates it
by WineHQ Bugzilla Aug. 15, 2026

Aug. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=60171 Bug ID: 60171 Summary: A click that falls through a native-surface-less active top-level window incorrectly deactivates it Product: Wine Version: 11.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Keywords: patch Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs(a)list.winehq.org Reporter: devel(a)velmeden.info Target Milestone: --- Distribution: ArchLinux Created attachment 81813 --> http://bugs.winehq.org/attachment.cgi?id=81813 Patch *I ran into this bug but could not find or reproduce the underlying cause myself, so I investigated it together with an AI assistant. The text and patch below is written by the AI, based on that interactive troubleshooting session.* ## Summary `process_mouse_message()` (`dlls/win32u/message.c`) reactivates whatever top-level window a click's X11 event resolves to, and deactivates the previously-active window as a side effect, whenever the clicked window differs from the currently active one. This is correct when the click is a genuine user action on a different window. It is wrong when the currently active top-level window has no native (X11) surface of its own: any click physically within that window's on-screen bounds can only ever be delivered by the X server to whatever real window happens to be underneath or around it (typically an ancestor), since the active window itself has nothing on screen to receive input. Wine currently can't tell these two cases apart, so it deactivates a window the user visually clicked on, purely because of how the click was routed at the X11 level. ## Why a top-level window can have no native surface Some applications create ordinary (non-`WS_CHILD`) top-level windows whose visible content is presented through some other mechanism than Wine's own X11 "whole window" — for example, a toolkit-hosted child surface embedded inside a native host window, where the toolkit's own window/surface object is what's actually on screen, while the win32-visible `HWND` exists purely for message routing, focus and activation bookkeeping. In such a case `X11DRV_get_whole_window(hwnd)` legitimately returns `0` for that `HWND` even though it is a real, activatable top-level window as far as the win32 window manager is concerned. ## Observed effect I diagnosed this on Wine 11.14 against Loxone Config (an MFC + Qt6 hybrid application), whose MDI document window is exactly such a case: its X11 "whole window" is destroyed early on and never recreated for the rest of the session (confirmed structural, not a transient timing gap — traced via `create_whole_window()`/`destroy_whole_window()` instrumentation across a full session), while Wine's own bookkeeping still tracks it as the active top-level window (`NtUserGetForegroundWindow()`/`info.hwndActive`). Any real mouse click physically over that window's on-screen area resolves, at the raw X11 level, to whichever window is actually behind it (confirmed via instrumented `X11DRV_ButtonPress` logging the raw event's `window`/`subwindow` fields together with each window's actual X11 id — the click's `ButtonPress` event targets the ancestor's real X11 window, never the document window's, because the latter doesn't have one). `process_mouse_message()` then runs its normal `WM_MOUSEACTIVATE`/`set_foreground_window()`/`set_active_window()` cascade for "a click on a different top-level window", which sends `WM_ACTIVATE(WA_INACTIVE)` to the window that was actually still active and that the click was visually intended for. Any interaction state that window's application logic keeps tied to activation (for example, a pending drag-and-drop-style operation initiated by an earlier click) gets torn down as a result, even though the user's click landed squarely inside that window's visible bounds. This does not require the click to race anything — in the traced case, the affected window had already been without a native surface for ~30 seconds before the failing click, so this is a deterministic misclassification, not a timing-sensitive race. ## Steps to reproduce 1. Download Loxone Config: https://updatefiles.loxone.com/LoxConfig/LoxoneConfigSetup_17010727.zip 2. Unzip it and run the installer under Wine: `wine LoxoneConfigSetup.exe` (click through the installer normally). 3. Launch `LoxoneConfig.exe` and open or create any project. 4. Pick any block/object to add, either via the search dialog (press `F5` to open it, type e.g. `RS` to find the "RS Flipflop" block, and pick it from the results) or by dragging one of the toolbar symbols — either way it attaches to the mouse cursor as a drag preview. 5. Move the mouse over the project canvas and click to place it. Expected: the block is placed on the canvas. Actual: the drag preview disappears on mouse-down, but no block is actually added — no visible change, and `Edit` → `Undo` stays greyed out, confirming the placement was never registered. This is 100% reproducible. ## Fix Attached patch adds a `WindowHasNativeSurface(HWND) -> BOOL` user driver entry point (default `TRUE`; implemented for `winex11.drv` via the existing `X11DRV_get_whole_window()` helper, other drivers unaffected). In `process_mouse_message()`, before running the reactivation cascade for a click that resolves to a different top-level window, check whether the window Wine still considers active has no native surface and geometrically contains the click point; if so, treat this as a click-through rather than a genuine activation change, and skip the cascade. The check is narrowly scoped: it does not redirect the click itself, does not touch window-surface creation/lifecycle, and every other click-resolution/activation path (including everything on drivers other than `winex11.drv`, where the new hook always returns `TRUE`) is unaffected. ## Testing - Live-validated against the real application described above: prior to the fix, the described interaction failed 100% of the time; after the fix, the specific click-misrouting-to-an-ancestor mechanism no longer tears down the document window's activation state (confirmed via the same gdb instrumentation, both on a debug and on a release (`-O2`) Wine build). - `dlls/user32/tests/msg.c` and `dlls/user32/tests/input.c` run clean (via an isolated `Xephyr` X server, since the interactive desktop proved too environment-sensitive for a byte-accurate baseline comparison): no activation/`WM_ACTIVATE`/`WM_MOUSEACTIVATE`-related failures attributable to the patch across multiple runs. ## Known limitation of this report I don't yet have a minimal, app-independent C reproduction case for this specific mechanism (a separate, previously-considered mechanism for the same user-facing symptom turned out, on later investigation, to be a distinct and still-open issue in the same application, unrelated to this patch). I'm glad to build one (the core ingredients — a top-level window with no native surface set as active, and a second, real window overlapping its screen area — should be reproducible with plain Win32 API plus one Wine-internal step to force the surface-less state) if that would help review; in the meantime the patch was developed and validated against a live repro that exhibits the exact structural condition described above, with full gdb-level traces at each step (raw X11 event routing, `set_active_window()` call arguments, and whole-window create/destroy lifecycle) establishing the mechanism precisely rather than by inference. -- 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.

1 4

[Bug 60153] New: Chip's Challenge 1: background music stops playing after restarting or completing a level
by WineHQ Bugzilla Aug. 15, 2026

Aug. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=60153 Bug ID: 60153 Summary: Chip's Challenge 1: background music stops playing after restarting or completing a level Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mfplat Assignee: wine-bugs(a)list.winehq.org Reporter: Patrick.M.Hoffer(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81769 --> http://bugs.winehq.org/attachment.cgi?id=81769 Wine 11.15 log Chip's Challenge 1 Steam AppID: 346850 PE32 executable for MS Windows 6.00 (GUI), Intel i386 wine-devel-11.15-1.1.x86_64 The game requires Steamworks, so I installed and ran the Windows Steam client inside the same Wine prefix and installed Chip's Challenge through that Steam client. Distribution: Nobara Linux Host architecture: x86_64 Audio stack: PipeWire using Wine's PulseAudio driver (winepulse.drv) Sound hardware / driver: See attached (wine-audio-info.txt) Prefix / configuration The issue was reproduced using a newly created Wine prefix: ~/.wine-chips-upstream No native Windows DLLs or DLL overrides were added. Wine was run from the unmodified WineHQ development package. Steps to reproduce Start the Windows Steam client using Wine 11.15. Launch Chip's Challenge from Steam. Start a level. Confirm that the background music is playing. Restart the level. The same issue can also occur after completing a level and proceeding to another level. Expected result Background music should start playing normally again after restarting or changing levels. Actual result Background music plays correctly when the first level starts. After restarting the level, the background music no longer plays. Sound effects continue to work normally. The game itself continues running and remains playable. Additional observations The game uses Media Foundation / MFPlay for its MP3 background music. In the Wine debug trace, the first successful playback reaches the expected playback sequence, including: media_player_CreateMediaItemFromURL media_player_SetMediaItem media_player_Play mfsession_Start MF_TOPOSTATUS_STARTED_SOURCE audio renderer clock start IAudioClient::Start After restarting the level, the game again: creates the same MP3 media item, calls SetMediaItem, calls Play, and calls IMFMediaSession::Start. However, the second playback attempt does not reach MF_TOPOSTATUS_STARTED_SOURCE, the audio renderer clock is not started again, and there is no second IAudioClient::Start. This may indicate a Media Foundation / MFPlay Media Session state or topology transition problem, but I am reporting the observable application behavior rather than assuming the exact cause. Other testing The same user-visible behavior also occurs with: Proton 9.0-4 Proton 10.0-4 Proton Experimental GE-Proton 7-1 current GE-Proton These are listed only as supplemental information. The WineHQ reproduction described above was performed with upstream Wine 11.15-devel. I also tested forcing the host PipeWire graph to 44.1 kHz; this did not change the behavior. The game's MP3 files were also temporarily converted from 44.1 kHz to 48 kHz to eliminate the Media Foundation resampling path as a variable. The music still stopped after restarting the level. Debug output A complete Wine terminal/debug log from the upstream Wine 11.15 reproduction is attached separately. The trace was captured with: WINEDEBUG=+mfplat,+mfplay,+mf,+winegstreamer,+mmdevapi,+pulse,+dmo,+timestamp The log is attached as plain text / compressed text rather than pasted into this report. -- 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.

1 2

[Bug 60173] New: winex11.drv: layered window is painted black when a Direct3D/OpenGL swap chain targets it (breaks every WPF menu, tooltip and AllowsTransparency window)
by WineHQ Bugzilla Aug. 14, 2026

Aug. 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=60173 Bug ID: 60173 Summary: winex11.drv: layered window is painted black when a Direct3D/OpenGL swap chain targets it (breaks every WPF menu, tooltip and AllowsTransparency window) Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: wehrwolfmann(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81819 --> http://bugs.winehq.org/attachment.cgi?id=81819 Minimal Win32 + D3D9Ex reproducer, with nod3d and plain control modes A top level layered window (WS_EX_LAYERED, contents supplied through UpdateLayeredWindow) is painted opaque black as soon as a Direct3D swap chain targets the same window. Without the swap chain the very same window, the very same bits and the very same UpdateLayeredWindow call paint correctly. This is what makes .NET WPF applications show black menus, black tooltips and black windows under Wine: WPF renders through Direct3D 9 by default, and every WPF popup (menu, combo box drop down, tooltip) as well as every window with AllowsTransparency="True" is a layered window. The widely quoted workaround [HKEY_CURRENT_USER\Software\Microsoft\Avalon.Graphics] "DisableHWAcceleration"=dword:00000001 works because it takes Direct3D out of the picture entirely, not because anything is wrong with WPF's use of the API. Measured on wine-11.15 and wine-staging-11.15, x86-64, winex11.drv, default wined3d GL renderer, KDE Plasma 6.7.4 on Wayland (Xwayland), Mesa "AMD Radeon 780M Graphics (radeonsi, phoenix, ACO, DRM 3.64)". HOW TO REPRODUCE (no .NET needed) --------------------------------- The attached d3d9_layered.c is ~190 lines of plain Win32 and does exactly what WPF's MilCore does for a transparent window: 1. create a WS_EX_LAYERED top level window 2. Direct3DCreate9Ex / CreateDeviceEx, windowed swap chain, hDeviceWindow = that window, back buffer D3DFMT_A8R8G8B8 3. Clear the back buffer to opaque red 0xFFFF0000 4. GetRenderTargetData(back buffer -> D3DPOOL_SYSTEMMEM surface) 5. LockRect that surface and hand the bits to UpdateLayeredWindow Build and run: x86_64-w64-mingw32-gcc -O1 -o d3d9_layered.exe d3d9_layered.c \ -ld3d9 -lgdi32 -luser32 wine d3d9_layered.exe # layered window + D3D9Ex wine d3d9_layered.exe nod3d # same layered window, no Direct3D (control) wine d3d9_layered.exe plain # ordinary window + D3D9Ex (control) The window stays up for 8 seconds so it can be looked at. Expected: a red 300x120 rectangle at 80,80 in all three cases. Actual: d3d9_layered.exe black rectangle <-- the bug d3d9_layered.exe nod3d red rectangle, correct d3d9_layered.exe plain red rectangle, correct Every Direct3D call succeeds and the read back data is correct, so the program also prints: Direct3DCreate9Ex hr=0x00000000 CreateDeviceEx hr=0x00000000 GetBackBuffer hr=0x00000000 SetRenderTarget hr=0x00000000 Clear(0xFFFF0000) hr=0x00000000 CreateOffscreenPlainSurf hr=0x00000000 GetRenderTargetData hr=0x00000000 LockRect hr=0x00000000 read back pixel(0,0) = 0xffff0000 (expected 0xffff0000) pixels wrong in row 0 = 0 of 300 UpdateLayeredWindow ok=1 VERDICT: readback ok That is, d3d9 and wined3d do their job: the pixels handed to UpdateLayeredWindow are the correct red, and UpdateLayeredWindow returns TRUE. The window is black all the same. THE SAME THING ON WPF --------------------- The attached wpf_layered.cs opens four things at once in one process: A ordinary Window -> renders, correct B Window, AllowsTransparency = true -> BLACK C Popup, AllowsTransparency = false -> renders, correct D Popup, AllowsTransparency = true -> BLACK so it is not "popups" and not "WPF" in general -- it is exactly the layered ones. It can be built inside a prefix that has .NET Framework 4.x with the in-box compiler, no Visual Studio and no SDK needed: wine C:\\windows\\Microsoft.NET\\Framework64\\v4.0.30319\\csc.exe \ /target:winexe /platform:x64 /out:C:\\wpf_layered.exe \ /r:<GAC_MSIL>\\PresentationFramework\\...\\PresentationFramework.dll \ /r:<GAC_64>\\PresentationCore\\...\\PresentationCore.dll \ /r:<GAC_MSIL>\\WindowsBase\\...\\WindowsBase.dll \ /r:<GAC_MSIL>\\System.Xaml\\...\\System.Xaml.dll \ C:\\wpf_layered.cs Screenshots "before" and "after" are attached. WHAT IS ACTUALLY HAPPENING -------------------------- The swap chain gives the window an X11 client window, and that client window is an opaque child sitting on top of everything the layered window painted. xwininfo while the repro is up: xwininfo: Window id: 0x5c00006 "layered" Parent window id: 0x350 (the root window) 1 child: 0x5a00036 (has no name): () 300x120+0+0 +80+80 The child covers the window completely. Without the Direct3D device there is no child and the window is red. winex11.drv already has the machinery for this case -- when a window needs compositing, the client window is detached and the rendering is redirected through XComposite (client_surface_update_offscreen() in dlls/winex11.drv/init.c). It is just never asked to do it for a layered window: BOOL needs_offscreen_rendering( HWND hwnd ) { if (NtUserGetDpiForWindow( hwnd ) != NtUserGetWinMonitorDpi( hwnd, MDT_RAW_DPI )) return TRUE; /* needs DPI scaling */ if (NtUserGetAncestor( hwnd, GA_PARENT ) != NtUserGetDesktopWindow()) return TRUE; /* child window, needs compositing */ if (NtUserGetWindowRelative( hwnd, GW_CHILD )) return needs_client_window_clipping( hwnd ); /* window has children, needs compositing */ return FALSE; } A layered window is composited by UpdateLayeredWindow into the window surface, so it needs the same treatment. Adding one condition: --- a/dlls/winex11.drv/init.c +++ b/dlls/winex11.drv/init.c @@ -222,6 +222,7 @@ static BOOL needs_client_window_clipping( HWND hwnd ) BOOL needs_offscreen_rendering( HWND hwnd ) { + if (NtUserGetWindowLongW( hwnd, GWL_EXSTYLE ) & WS_EX_LAYERED) return TRUE; /* layered window, contents are composited by UpdateLayeredWindow */ if (NtUserGetDpiForWindow( hwnd ) != NtUserGetWinMonitorDpi( hwnd, MDT_RAW_DPI )) return TRUE; /* needs DPI scaling */ makes all of it correct: the C repro draws its red rectangle, and A/B/C/D of the WPF test all render. Measured by taking a screenshot and reading the pixel at the centre of the window, same build, same prefix, same binaries otherwise: before the change pixel = rgb(0,0,0) after the change pixel = rgb(255,0,0) I am not proposing that one-liner as the finished patch -- somebody who knows the driver will want to decide whether it should be keyed on the layered flag, on data->layered, or only when a client surface actually exists, and whether winewayland.drv needs the same. It is offered as the smallest change that demonstrates where the problem is. I did not manage to get winewayland.drv up in this session, so this report covers winex11.drv only. RELATION TO OTHER BUGS ---------------------- Bug 49055 ("Multiple .NET WPF 4.x applications show black screen or have broken user interface rendering") is the same user visible symptom and the same DisableHWAcceleration workaround. This is a different root cause from the viewport-scoped Clear() problem discussed there in comments #2..#6, so I filed it separately rather than piling onto that bug; feel free to merge them if you disagree. Bug 32507 is about how UpdateLayeredWindow interprets the alpha channel, which is a different question -- here the alpha handling never gets a chance to matter, because the painted result is hidden by the client 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.

1 4

[Bug 57264] New: zsh: killed wineboot --init
by WineHQ Bugzilla Aug. 14, 2026

Aug. 14, 2026

https://bugs.winehq.org/show_bug.cgi?id=57264 Bug ID: 57264 Summary: zsh: killed wineboot --init Product: Wine Version: unspecified Hardware: aarch64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: activeds Assignee: wine-bugs(a)winehq.org Reporter: euloanty(a)live.com Cannot run wine on arm darwin why? -- 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.

2 11

[Bug 55432] New: PlanetSide 2: White screen when running launcher
by WineHQ Bugzilla Aug. 14, 2026

Aug. 14, 2026

https://bugs.winehq.org/show_bug.cgi?id=55432 Bug ID: 55432 Summary: PlanetSide 2: White screen when running launcher Product: Wine Version: 8.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdiplus Assignee: wine-bugs(a)winehq.org Reporter: linards.liepins(a)gmail.com Distribution: --- I am using Steam, so when I click "Play" in Steam, the black screen whith DayBreak logo appears for a second or two, and then it says for few more moments black and then turns all white. After following the suggestion to add "--disable-gpu" in https://www.reddit.com/r/linux_gaming/comments/va7qag/planetside_2_only_loa… , launcher starts just fine. After that, the BattleEye error occurs, blocking to run the game. System: $ inxi -Gxxx Graphics: Device-1: Intel DG2 [Arc A770] driver: i915 v: kernel arch: Gen-12.7 pcie: speed: 2.5 GT/s lanes: 1 ports: active: HDMI-A-1,HDMI-A-2 empty: DP-1, DP-2, DP-3, DP-4, HDMI-A-3 bus-ID: 03:00.0 chip-ID: 8086:56a0 class-ID: 0300 Display: wayland server: X.org v: 1.20.14 with: Xwayland v: 22.1.9 compositor: gnome-shell v: 44.3 driver: gpu: i915 display-ID: 0 Monitor-1: HDMI-A-1 model: BenQ G2420HDBL serial: RAB03454SL000 res: 1920x1080 dpi: 92 size: 477x268mm (18.78x10.55") diag: 604mm (23.8") modes: max: 1920x1080 min: 720x400 Monitor-2: HDMI-A-2 model: Philips FTV serial: 16843009 res: 1920x1080 dpi: 76 size: 640x360mm (25.2x14.17") diag: 734mm (28.9") modes: max: 1920x1080 min: 640x480 API: OpenGL v: 4.6 Mesa 23.1.5 renderer: Mesa Intel Arc A770 Graphics (DG2) direct-render: Yes -- 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.

2 11

[Bug 7054] Pure Pinball game crashes trying to access freed texture objects
by WineHQ Bugzilla Aug. 14, 2026

Aug. 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=7054 nikolas.gur(a)stud.uni-due.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nikolas.gur(a)stud.uni-due.de --- Comment #24 from nikolas.gur(a)stud.uni-due.de --- bug still present in wine-11.15, same as the Redux version (https://bugs.winehq.org/show_bug.cgi?id=55612) -- 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.

1 0

[Bug 56780] New: Multiple games skip playing cutscenes (The Long Dark, The Room 4: Old Sins, Saint Kotar)
by WineHQ Bugzilla Aug. 14, 2026

Aug. 14, 2026

https://bugs.winehq.org/show_bug.cgi?id=56780 Bug ID: 56780 Summary: Multiple games skip playing cutscenes (The Long Dark, The Room 4: Old Sins, Saint Kotar) Product: Wine Version: 9.10 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: mfplat Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com Distribution: --- Continuation of bug 50983. 068c:fixme:mfplat:media_source_get_service_GetService Unsupported service {dd0ac3d8-40e3-4128-ac48-c0add067b714}. 068c:fixme:mfplat:MFPluginControl_IsDisabled (0 {88753b26-5b24-49bd-b2e7-0c445c78c982}) 068c:fixme:mfplat:MFPluginControl_GetPreferredClsidByIndex (0 0 00007FB6AC36F2B8 00007FB6AC36F2E0) 0718:fixme:mfplat:video_processor_ProcessMessage Ignoring message 0. 9.10-32-gb6abacbb7b0 -- 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.

2 5

[Bug 22253] New: Total Commander: Scrolling with the mouse wheel does not work in Brief view
by wine-bugs＠winehq.org Aug. 14, 2026

Aug. 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=22253 Summary: Total Commander: Scrolling with the mouse wheel does not work in Brief view Product: Wine Version: 1.1.41 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: trivial Priority: P3 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: alexandru.balut(a)gmail.com Go to c:\windows\system32\, Ctrl F1 (or Show -> Brief), notice a horizontal scrollbar appear. Scroll "down" with the mouse wheel. The scroll bar should go right, but nothing happens. Press PageDown to go to the end of the file list. Scroll "up" using the mouse wheel, notice the scroll bar goes left. But scrolling "down" still does not work.. In Ctrl F2 (showing full file details) there is a vertical scrollbar, and scrolling there using the mouse wheel works fine. Total Commander 7.50a Ubuntu 9.10 -- 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.

2 14