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

[Bug 59656] New: HDPVP crashes at startup with Unhandled division by zero at address
by WineHQ Bugzilla April 15, 2026

April 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59656 Bug ID: 59656 Summary: HDPVP crashes at startup with Unhandled division by zero at address Product: Wine Version: 11.6 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: opengl Assignee: wine-bugs(a)list.winehq.org Reporter: afifsworld132(a)gmail.com Created attachment 80747 --> http://bugs.winehq.org/attachment.cgi?id=80747 Log of game with +opengl,+d3d, opening from Steam System: MacBook Pro M1 (2020), macOS 14.1.1, Wine Staging 11.6, DXMT 0.74, Game (HYPER PVP DEMON) is from Steam. The game crashes at startup with a terminal. The game creates a log file next to the .exe which has: ``` LOG: 0 WGL: Failed to create OpenGL context _crash_ ``` This could be due to the game requirements: Dedicated GPU with OpenGL 3.3 support -- 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 1

[Bug 59653] New: winex11.drv: FocusOut sends WM_CANCELMODE during active mouse grab, breaking drag operations
by WineHQ Bugzilla April 14, 2026

April 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59653 Bug ID: 59653 Summary: winex11.drv: FocusOut sends WM_CANCELMODE during active mouse grab, breaking drag operations Product: Wine Version: 11.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: lldmakhbfcrmqyluns(a)nesopf.com Distribution: --- When a Wine application performs a drag operation (which involves an active mouse capture via SetCapture), and the user switches focus with Alt+Tab, XWayland sends a FocusOut event to the Wine window. Currently, Wine's focus_out() handler in dlls/winex11.drv/event.c unconditionally sends a WM_CANCELMODE message to the window losing focus. This forces any well-behaved Win32 application to call ReleaseCapture() and abort the modal drag operation. This behavior is incorrect. On native Windows, an active mouse capture survives keyboard focus changes. WM_CANCELMODE should not be sent in this state. This issue is specific to the winex11.drv backend and is prominently observed on XWayland. The native winewayland.drv does not suffer from this issue, as it handles input grabs differently. The successful drag-and-drop in native Wayland mode (with the ole32 fix applied) further proves that this is an X11-specific event handling bug. Steps to Reproduce: Implement patch from bug #59652 to enable drag and drop. Run Wine under an XWayland session. Start two applications (e.g., a file manager and a text editor). In the source application, begin a drag operation by holding the left mouse button. While still holding the mouse button, press Alt+Tab to switch focus to the other application. Actual Results: The drag operation is silently cancelled. Expected Results: The drag operation should continue, allowing the user to complete the drop in the other window. Patch: The following patch modifies focus_out() to check for an active mouse grab (grab_hwnd) before sending WM_CANCELMODE. This aligns Wine's behavior with native Windows and fixes the bug. diff --- a/dlls/winex11.drv/event.c +++ b/dlls/winex11.drv/event.c @@ -2019,7 +2019,15 @@ set_focus( thread_data, NULL, NULL ); if (!(NtUserGetWindowLongW( hwnd, GWL_STYLE ) & WS_MINIMIZE)) - send_message( hwnd, WM_CANCELMODE, 0, 0 ); + { + if (x11drv_thread_data()->grab_hwnd) + { + TRACE("Skipping WM_CANCELMODE, mouse is grabbed by %p.\\n", x11drv_thread_data()->grab_hwnd); + } + else + send_message( hwnd, WM_CANCELMODE, 0, 0 ); + } if (X11DRV_GetKeyboardLayout(0) != get_thread_input_hkl(0)) X11DRV_ActivateKeyboardLayout( get_thread_input_hkl(0), 0 ); -- 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 3

[Bug 59652] New: ole32: DoDragDrop does not fall back to WM_DROPFILES for legacy applications
by WineHQ Bugzilla April 14, 2026

April 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59652 Bug ID: 59652 Summary: ole32: DoDragDrop does not fall back to WM_DROPFILES for legacy applications Product: Wine Version: 11.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ole32 Assignee: wine-bugs(a)list.winehq.org Reporter: lldmakhbfcrmqyluns(a)nesopf.com Distribution: --- In Microsoft Windows, when an OLE Drag & Drop source application (using DoDragDrop) drops data onto a target application that does not implement IDropTarget but has the WS_EX_ACCEPTFILES style, the ole32.dll library automatically acts as a bridge. It extracts CF_HDROP data, allocates memory in the target process, and posts a WM_DROPFILES message. Currently, Wine's ole32.dll does not implement this fallback mechanism. If IDropTarget is not found on the target window, Wine simply returns DROPEFFECT_NONE and aborts the operation, even if a drop was requested (DRAGDROP_S_DROP). This breaks drag-and-drop functionality for many legacy applications that rely on WM_DROPFILES. Steps to Reproduce: Run an OLE-aware application that can act as a drag source (e.g., Total Commander, modern file explorers). Run a legacy application that accepts files via WM_DROPFILES but does not implement OLE IDropTarget (e.g., Notepad++, etc.). Drag a file from the source application to the target application. Actual Results: The drop fails. DoDragDrop returns DROPEFFECT_NONE. Expected Results: The file should be successfully dropped and opened by the target application, as it happens on Windows. Patch: The following patch implements the WM_DROPFILES fallback bridge in dlls/ole32/ole2.c. It correctly identifies legacy targets, marshals the CF_HDROP data into the target process, and posts the WM_DROPFILES message. This fixes the issue in both XWayland and native Wayland backend. diff --- a/dlls/ole32/ole2.c +++ b/dlls/ole32/ole2.c @@ -2246,6 +2246,90 @@ return target; } +/* WM_DROPFILES bridge for legacy apps without IDropTarget */ +typedef struct { + DWORD pFiles; + POINT pt; + BOOL fNC; + BOOL fWide; +} WINE_DROPFILES; + +static HWND find_drop_target(POINT pt) +{ + HWND walk = GetTopWindow(GetDesktopWindow()); + DWORD our_pid = GetCurrentProcessId(); + + while (walk) { + if (IsWindowVisible(walk)) { + RECT rc; + DWORD wpid = 0; + GetWindowThreadProcessId(walk, &wpid); + if (wpid && wpid != our_pid) { + GetWindowRect(walk, &rc); + if (PtInRect(&rc, pt)) { + HWND target = walk; + while (target) { + if (GetWindowLongW(target, GWL_EXSTYLE) & WS_EX_ACCEPTFILES) + return target; + target = GetParent(target); + } + return walk; + } + } + } + walk = GetWindow(walk, GW_HWNDNEXT); + } + return NULL; +} + +static BOOL bridge_wm_dropfiles(IDataObject *dataObject, HWND target, POINT pt) +{ + FORMATETC fmt = { CF_HDROP, NULL, DVASPECT_CONTENT, -1, TYMED_HGLOBAL }; + STGMEDIUM stg; + WINE_DROPFILES *df; + DWORD target_pid; + HANDLE hProc; + SIZE_T size; + void *remote; + + if (FAILED(IDataObject_GetData(dataObject, &fmt, &stg))) + return FALSE; + if (stg.tymed != TYMED_HGLOBAL || !stg.hGlobal) { + ReleaseStgMedium(&stg); + return FALSE; + } + + df = GlobalLock(stg.hGlobal); + if (!df) { + ReleaseStgMedium(&stg); + return FALSE; + } + size = GlobalSize(stg.hGlobal); + df->pt = pt; + df->fNC = FALSE; + + GetWindowThreadProcessId(target, &target_pid); + hProc = OpenProcess(PROCESS_VM_OPERATION | PROCESS_VM_WRITE, FALSE, target_pid); + if (!hProc) { + GlobalUnlock(stg.hGlobal); + ReleaseStgMedium(&stg); + return FALSE; + } + + remote = VirtualAllocEx(hProc, NULL, size, MEM_COMMIT, PAGE_READWRITE); + if (remote) { + WriteProcessMemory(hProc, remote, df, size, NULL); + PostMessageW(target, WM_DROPFILES, (WPARAM)remote, 0); + } + + CloseHandle(hProc); + GlobalUnlock(stg.hGlobal); + ReleaseStgMedium(&stg); + return remote != NULL; +} + static void drag_end( TrackerWindowInfo *info ) { HRESULT hr; @@ -2279,6 +2363,17 @@ else *info->pdwEffect = DROPEFFECT_NONE; + /* Bridge OLE drop to WM_DROPFILES for legacy apps */ + if (*info->pdwEffect == DROPEFFECT_NONE && info->returnValue == DRAGDROP_S_DROP) + { + POINT pt; + HWND target; + pt.x = info->curMousePos.x; + pt.y = info->curMousePos.y; + target = find_drop_target(pt); + if (target && bridge_wm_dropfiles(info->dataObject, target, pt)) + *info->pdwEffect = DROPEFFECT_COPY; + } } static HRESULT give_feedback( TrackerWindowInfo *info ) -- 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 3

[Bug 59650] New: wayland: Modifier keys (Alt/Ctrl) get stuck when window loses focus due to race condition in release_all_keys()
by WineHQ Bugzilla April 14, 2026

April 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59650 Bug ID: 59650 Summary: wayland: Modifier keys (Alt/Ctrl) get stuck when window loses focus due to race condition in release_all_keys() Product: Wine Version: 11.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winewayland Assignee: wine-bugs(a)list.winehq.org Reporter: lldmakhbfcrmqyluns(a)nesopf.com Distribution: --- Symptoms: When using native Wayland, pressing a global window manager shortcut (like Alt+Tab or a custom Ctrl+Tab bound in KWin) causes the modifier key to become permanently "stuck" inside the Wine application. For example, after Alt+Tab out of the application and returning to it, the application behaves as if Alt is still held down, immediately activating the window's top menu bar (VK_MENU). The issue is absent in X Wayland. Steps to reproduce: Run any 2 application in Wayland Wine. Press Alt+Tab several times to trigger windows switching. The application acts as if the Alt modifier is still pressed. Technical Analysis (Root Cause): With WINEDEBUG=+waylanddrv,+keyboard,+key, the log shows that Wayland sends the key press event, immediately followed by the wl_keyboard.leave event. However, the key release is never generated by Wine. The bug is a Race Condition located in dlls/winewayland.drv/wayland_keyboard.c within the release_all_keys(HWND hwnd) function. Currently, when keyboard_handle_leave is called, it triggers release_all_keys. This function uses NtUserGetAsyncKeyboardState(state) to check which keys need a synthetic KEYUP event: c static void release_all_keys(HWND hwnd) { BYTE state[256]; NtUserGetAsyncKeyboardState(state); // ... sends KEYUP if state[vkey] & 0x80 } Because Wayland events are processed very fast, the initial wl_keyboard.key (pressed) event is sent to the Wine server queue via NtUserSendHardwareInput, but the server has not processed it yet. When NtUserGetAsyncKeyboardState is immediately called during the leave event, the server reports that the key is not pressed. Therefore, release_all_keys skips sending the KEYUP event. Milliseconds later, the server processes the KEYDOWN, and the key becomes stuck forever. Proposed Solution / Patch: The Wayland driver must not rely on the asynchronous Wine server state to release keys during focus loss. It should maintain its own local array of physically pressed evdev keys and release them accordingly. Here is a proposed patch to fix this issue: diff --- a/dlls/winewayland.drv/wayland_keyboard.c +++ b/dlls/winewayland.drv/wayland_keyboard.c @@ -79,6 +79,9 @@ static struct rxkb_context *rxkb_context; static HKL keyboard_hkl; /* the HKL matching the currently active xkb group */ +/* Local state to track physically pressed keys to avoid race conditions with wine server */ +static BYTE wayland_pressed_keys[KEY_MAX]; + void activate_keyboard_hkl(HWND hwnd, BOOL ime) { HKL hkl = ime && !is_ime_hkl(keyboard_hkl) ? get_ime_hkl(LOWORD(keyboard_hkl)) : keyboard_hkl; @@ -430,24 +433,23 @@ static void release_all_keys(HWND hwnd) { - BYTE state[256]; - int vkey; - INPUT input = {.type = INPUT_KEYBOARD}; - - NtUserGetAsyncKeyboardState(state); - - for (vkey = 1; vkey < 256; vkey++) + int key; + + for (key = 0; key < ARRAY_SIZE(wayland_pressed_keys); key++) { - /* Skip mouse buttons. */ - if (vkey < 7 && vkey != VK_CANCEL) continue; - /* Skip left/right-agnostic modifier vkeys. */ - if (vkey == VK_SHIFT || vkey == VK_CONTROL || vkey == VK_MENU) continue; - - if (state[vkey] & 0x80) + if (wayland_pressed_keys[key]) { - UINT scan = NtUserMapVirtualKeyEx(vkey, MAPVK_VK_TO_VSC_EX, - keyboard_hkl); - input.ki.wVk = vkey; + UINT scan = key2scan(key); + INPUT input = {0}; + + if (key == KEY_RIGHTALT) send_right_control(hwnd, WL_KEYBOARD_KEY_STATE_RELEASED); + + input.type = INPUT_KEYBOARD; + input.ki.wScan = (scan & 0x300) ? scan + 0xdf00 : scan; + input.ki.dwFlags = KEYEVENTF_SCANCODE | KEYEVENTF_KEYUP; + if (scan & ~0xff) input.ki.dwFlags |= KEYEVENTF_EXTENDEDKEY; + + NtUserSendHardwareInput(hwnd, 0, &input, 0); + + wayland_pressed_keys[key] = 0; } } } @@ -524,6 +526,9 @@ InterlockedExchange(&process_wayland.input_serial, serial); + if (key < ARRAY_SIZE(wayland_pressed_keys)) + wayland_pressed_keys[key] = (state == WL_KEYBOARD_KEY_STATE_PRESSED); + if (!(hwnd = wayland_keyboard_get_focused_hwnd())) return; TRACE_(key)("serial=%u hwnd=%p key=%d scan=%#x state=%#x\n", serial, hwnd, key, scan, state); -- 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 59616] New: CF_HDROP export to text/uri-list incorrectly URL-encodes slashes ('/'), breaking file pasting in native Linux file dialogs
by WineHQ Bugzilla April 14, 2026

April 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59616 Bug ID: 59616 Summary: CF_HDROP export to text/uri-list incorrectly URL-encodes slashes ('/'), breaking file pasting in native Linux file dialogs Product: Wine Version: 11.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: lldmakhbfcrmqyluns(a)nesopf.com Distribution: --- Component: x11drv (not in the list) When copying a file from a Wine application (e.g., Wine Explorer, Total Commander) and pasting it into a native Linux application's "File -> Open" dialog (e.g., KDE/Qt), the pasted URI is completely broken. The path is pasted with URL-encoded directory separators (e.g., `file:///home%2Fuser%2F.wine%2Fdosdevices%2Fc%3A%2Ffile.jpg`). Native Linux file dialogs fail to open this because they interpret `%2F` as a literal character in a filename, not as a directory separator. Steps to Reproduce: 1. Open any file manager inside Wine. 2. Select a file and press Ctrl+C (copying it to the clipboard). 3. Open a native Linux application (e.g., Kate, Firefox, Telegram). 4. Open the "File -> Open" dialog or trigger a paste action. 5. Press Ctrl+V in the filename/path field. Actual Result: The pasted string is: `file:///home%2Fuser%2F.wine%2Fdosdevices%2Fc%3A%2Ffile.jpg` The Linux app throws a "File not found" error. Expected Result: The pasted string should be: `file:///home/user/.wine/dosdevices/c:/file.jpg` (Spaces and non-ASCII characters should still be encoded, but structural delimiters like '/' and ':' must be preserved). Root Cause Analysis: The bug is located in `dlls/winex11.drv/clipboard.c`, inside the `export_hdrop` function. There is a comment in the code that says: /* URL encode everything - unnecessary, but easier/lighter than linking in shlwapi, and can't hurt */ However, "encoding everything" *does* hurt. By encoding the forward slash ('/'), the code violates RFC 3986 section 3.3, which states that the path component consists of segments separated by slash ('/') characters. When the slash itself is percent-encoded, URI parsers treat the entire path as a single filename segment. Proposed Fix / Patch: We need to preserve unreserved characters and structural delimiters (like '/', ':', '.', '-', '_') while still encoding spaces and Unicode characters (e.g., Cyrillic) to maintain valid URIs. Here is the tested and working replacement for the encoding loop in `dlls/winex11.drv/clipboard.c`: /* URL encode, but preserve structural delimiters and alphanumeric chars (RFC 3986) */ for (u = 1; unixFilename[u]; u++) { char ch = unixFilename[u]; if (ch == '/' || ch == ':' || ch == '.' || ch == '-' || ch == '_' || ch == '~' || (ch >= 'a' && ch <= 'z') || (ch >= 'A' && ch <= 'Z') || (ch >= '0' && ch <= '9')) { textUriList[next++] = ch; } else { static const char hex_table[] = "0123456789abcdef"; textUriList[next++] = '%'; textUriList[next++] = hex_table[(unsigned char)ch >> 4]; textUriList[next++] = hex_table[ch & 0xf]; } } I have compiled and tested this patch locally on KDE Plasma (Wayland/Xwayland). It perfectly resolves the issue: files with spaces/Cyrillic are still properly encoded (e.g., `%20`), but slashes are preserved, allowing native Linux UI to parse and open the files instantly via clipboard. -- 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 59655] New: comctl32: Infinite WM_PAINT loop in SysListView32 when parent triggers layout update during NM_CUSTOMDRAW (MPC-BE)
by WineHQ Bugzilla April 14, 2026

April 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59655 Bug ID: 59655 Summary: comctl32: Infinite WM_PAINT loop in SysListView32 when parent triggers layout update during NM_CUSTOMDRAW (MPC-BE) Product: Wine Version: 11.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: comctl32 Assignee: wine-bugs(a)list.winehq.org Reporter: lldmakhbfcrmqyluns(a)nesopf.com Distribution: --- Steps to reproduce: Open MPC-BE. Ensure the Playlist panel is visible (View -> Playlist). Click on the top of the playlist window. The application GUI freezes permanently. Analysis / Root Cause: By adding extensive custom tracing to dlls/comctl32/listview.c, an infinite WM_PAINT loop was identified. Here is what happens during a single iteration of the loop: WM_PAINT is dispatched, calling LISTVIEW_Refresh. LISTVIEW_Refresh sets infoPtr->bIsDrawing = TRUE and starts drawing. During the drawing process, the listview sends NM_CUSTOMDRAW (stage CDDS_PREPAINT / CDDS_ITEMPREPAINT) to the parent window (MPC-BE). The parent's custom draw handler executes logic that indirectly triggers a layout update of the listview (e.g., via SetWindowPos on the header or changing item metrics). This layout update calls LISTVIEW_UpdateSize, which eventually calls LISTVIEW_InvalidateList. LISTVIEW_InvalidateList calls LISTVIEW_InvalidateRect(infoPtr, NULL), marking the entire client area as dirty. LISTVIEW_Refresh finishes and sets infoPtr->bIsDrawing = FALSE. Because the client area was invalidated during step 6, the system immediately generates a new WM_PAINT message. The cycle repeats indefinitely. Native Windows does not freeze, suggesting it ignores invalidation requests while the control is already actively painting itself. The Fix: The LISTVIEW_INFO structure already contains the bIsDrawing flag specifically to prevent reentrancy issues. The fix is to simply return early from LISTVIEW_InvalidateList if bIsDrawing is TRUE. Since LISTVIEW_Refresh is currently repainting the entire visible area anyway, queuing another full invalidation is both redundant and dangerous. Patch / Diff diff --- a/dlls/comctl32/listview.c +++ b/dlls/comctl32/listview.c @@ -1792,6 +1792,7 @@ static inline void LISTVIEW_InvalidateList(const LISTVIEW_INFO *infoPtr) { + if (infoPtr->bIsDrawing) return; LISTVIEW_InvalidateRect(infoPtr, NULL); } -- 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 3

[Bug 59609] New: comctl32: LVM_GETITEMPOSITION returns client coordinates instead of view coordinates in ICON/SMALLICON views (breaks FastStone Image Viewer)
by WineHQ Bugzilla April 14, 2026

April 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59609 Bug ID: 59609 Summary: comctl32: LVM_GETITEMPOSITION returns client coordinates instead of view coordinates in ICON/SMALLICON views (breaks FastStone Image Viewer) Product: Wine Version: 11.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: comctl32 Assignee: wine-bugs(a)list.winehq.org Reporter: lldmakhbfcrmqyluns(a)nesopf.com Distribution: --- Bug overview: In `dlls/comctl32/listview.c`, the function `LISTVIEW_GetItemPosition` unconditionally adds `Origin.x` and `Origin.y` to the item's coordinates. This converts the coordinates to Client coordinates. However, according to MSDN, for `LV_VIEW_ICON` and `LV_VIEW_SMALLICON` modes, `LVM_GETITEMPOSITION` must return View coordinates (absolute coordinates on the canvas), not Client coordinates. MSDN Documentation reference for LVM_GETITEMPOSITION: "In icon or small icon view, the LVM_GETITEMPOSITION message returns the item's position in view coordinates. To get the client coordinates of an item, subtract the origin from the view coordinates." Symptoms & Application Behavior: This bug breaks the top thumbnail strip in full screen mode of FastStone Image Viewer (FSViewer.exe) when scrolling horizontally. The thumbnail strip is a ListView in Icon mode (height: 150px). When the user scrolls to the right by approximately the width of the screen (e.g., ~1900px on a 1080p monitor), the thumbnails suddenly disappear, leaving blank white spaces and cropped thumbnails. The Mathematical Root Cause: Because Wine incorrectly returns Client coordinates instead of View coordinates, a "double subtraction" occurs in the application's logic: 1. Wine calculates internally: `Returned_X = Absolute_X - ScrollPos` (by adding the negative Origin). 2. FSViewer (following MSDN) attempts to calculate the client position to determine if the item is visible: `App_Client_X = Returned_X - ScrollPos`. 3. The resulting math is: `App_Client_X = Absolute_X - 2 * ScrollPos`. When `ScrollPos` exceeds the width of the window (e.g., scrolling past 1920px), the calculated right edge of the visible items becomes negative. FSViewer incorrectly concludes that all items have moved off-screen to the left. To save resources, FSViewer returns `CDRF_SKIPDEFAULT` (0x4) during the `CDDS_PREPAINT` custom draw notification. Wine respects this flag, skips drawing the items, and `BitBlt` copies a blank/white double-buffer background to the screen. Proposed Fix / Patch: The addition of `Origin` should be restricted to `LV_VIEW_DETAILS` and `LV_VIEW_LIST` views, where Client coordinates are actually expected. In `dlls/comctl32/listview.c`, modify `LISTVIEW_GetItemPosition`: --- a/dlls/comctl32/listview.c +++ b/dlls/comctl32/listview.c @@ -XXXX,X +XXXX,X @@ static BOOL LISTVIEW_GetItemPosition(const LISTVIEW_INFO *infoPtr, INT nItem, LP if (infoPtr->uView == LV_VIEW_ICON) { lpptPosition->x += (infoPtr->nItemWidth - infoPtr->iconSize.cx) / 2; lpptPosition->y += ICON_TOP_PADDING; } - lpptPosition->x += Origin.x; - lpptPosition->y += Origin.y; + + /* In Icon/SmallIcon views, position is in view coordinates (absolute). + * In Details/List views, position is in client coordinates. */ + if (infoPtr->uView == LV_VIEW_DETAILS || infoPtr->uView == LV_VIEW_LIST) + { + lpptPosition->x += Origin.x; + lpptPosition->y += Origin.y; + } TRACE (" lpptPosition=%s\n", wine_dbgstr_point(lpptPosition)); return TRUE; Testing: Applying this exact logic fully resolves the white-space rendering bug in FastStone Image Viewer without breaking standard ListView internal mechanics (since Wine internally relies on `LISTVIEW_GetItemOrigin` for drawing, which remains unaffected). -- 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 59591] New: Total Commander brief view jumps upward after rename due to inconsistent top_item clamping in comctl32_v6 listbox
by WineHQ Bugzilla April 14, 2026

April 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59591 Bug ID: 59591 Summary: Total Commander brief view jumps upward after rename due to inconsistent top_item clamping in comctl32_v6 listbox Product: Wine Version: 11.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: comctl32 Assignee: wine-bugs(a)list.winehq.org Reporter: lldmakhbfcrmqyluns(a)nesopf.com Distribution: --- Reproduced with Wine devel 11.4 on Kubuntu 25.10 using Total Commander in brief view. Steps to reproduce: 1. Start Total Commander. 2. Open a directory with enough files to make the brief view span multiple columns. 3. Switch the panel to brief view. 4. Scroll to the bottom / end of the file list. 5. Rename the last file (Enter) or otherwise trigger a content refresh. 6. Observe that the panel jumps upward instead of keeping the previous scroll position. Expected result: The panel should keep the same visible position after the rename / redraw. Actual result: The top item is moved upwards after the redraw. Investigation: The affected control is not user32 listbox but the comctl32_v6 listbox implementation in: dlls/comctl32_v6/listbox.c The problem is that top_item is clamped inconsistently in two different code paths: 1. LISTBOX_SetTopItem() clamps top_item via: LISTBOX_GetMaxTopIndex( descr ) 2. LISTBOX_SetRedraw() later reclamps it via: descr->nb_items - descr->page_size In brief / multi-column listbox mode these two values are not equivalent. In the failing case I traced, LISTBOX_SetTopItem() restored: top_item = 140 for a list with: nb_items = 157 Later LISTBOX_SetRedraw() reclamped the same listbox to: top_item = 122 That secondary clamp caused the visible upward jump. Proposed fix: Use LISTBOX_GetMaxTopIndex( descr ) in LISTBOX_SetRedraw() as well, so both code paths use the same limit. Patch: diff --git a/dlls/comctl32_v6/listbox.c b/dlls/comctl32_v6/listbox.c index 7dec0e2d999..d2029cca434 100644 --- a/dlls/comctl32_v6/listbox.c +++ b/dlls/comctl32_v6/listbox.c @@ -730,8 +730,7 @@ static void LISTBOX_SetRedraw( LB_DESCR *descr, BOOL on ) InvalidateRect(descr->self, NULL, TRUE); if ((descr->top_item + descr->page_size) > descr->nb_items) { /* reset top of page if less than number of items/page */ - descr->top_item = descr->nb_items - descr->page_size; - if (descr->top_item < 0) descr->top_item = 0; + descr->top_item = LISTBOX_GetMaxTopIndex( descr ); } descr->style &= ~LBS_DISPLAYCHANGED; } This fixes the issue locally for me: after rebuilding and replacing comctl32_v6.dll, the panel no longer jumps upward after rename/refresh in brief view. -- 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 59505] License activation crashes VOCALOID Authorizer application
by WineHQ Bugzilla April 14, 2026

April 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59505 --- Comment #2 from lyam.zambaz(a)pm.me --- (In reply to lyam.zambaz from comment #1) > Hello, > > You probably already knew it, but to spare research time for others, you can > just use the offline activation. > I still need to search why the Editor think it's not activated even if it is. [Update]: The second claim (that the Editor think it's not activated) it wrong. I just copied the offline activation file, thinking it would work. So no problem here :) -- 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 59505] License activation crashes VOCALOID Authorizer application
by WineHQ Bugzilla April 14, 2026

April 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59505 lyam.zambaz(a)pm.me changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lyam.zambaz(a)pm.me --- Comment #1 from lyam.zambaz(a)pm.me --- Hello, You probably already knew it, but to spare research time for others, you can just use the offline activation. I still need to search why the Editor think it's not activated even if it is. -- 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