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

[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 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

[Bug 59304] New: FlatOut 2 needs "m4x4" instruction support
by WineHQ Bugzilla April 14, 2026

April 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59304 Bug ID: 59304 Summary: FlatOut 2 needs "m4x4" instruction support Product: vkd3d Version: 1.18 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: hlsl Assignee: wine-bugs(a)list.winehq.org Reporter: andrey.goosev(a)gmail.com Distribution: --- 083c:fixme:d3d_shader:shader_spirv_compile_shader Shader log: 083c:fixme:d3d_shader:shader_spirv_compile_shader <anonymous>:4:0: E2007: Unhandled instruction "m4x4" (0xd2). 083c:fixme:d3d_shader:shader_spirv_compile_shader 083c:err:d3d_shader:shader_spirv_compile_shader Failed to compile shader, ret -4. 083c:err:d3d:wined3d_context_vk_apply_draw_state No pipeline layout set. 083c:err:d3d:adapter_vk_draw_primitive Failed to apply draw state. vkd3d-1.18-211-gd9210a62 -- 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 6

[Bug 51566] New: Project CARS 3 crashes on launch with Shadows disabled
by WineHQ Bugzilla April 14, 2026

April 14, 2026

https://bugs.winehq.org/show_bug.cgi?id=51566 Bug ID: 51566 Summary: Project CARS 3 crashes on launch with Shadows disabled Product: Wine Version: 6.14 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com Distribution: --- Created attachment 70412 --> https://bugs.winehq.org/attachment.cgi?id=70412 log 0148:warn:d3d11:d3d_texture2d_create Failed to create wined3d texture, hr 0x8876086c. wine-6.14-171-g3f2850aeaa1 -- 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 1

[Bug 59396] New: Tabbed UI in proprietary IDE broken after update – tabs are shown as separate windows
by WineHQ Bugzilla April 14, 2026

April 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59396 Bug ID: 59396 Summary: Tabbed UI in proprietary IDE broken after update – tabs are shown as separate windows Product: Wine Version: 11.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: Wagner.a18(a)yahoo.com Distribution: --- Since a recent update of a proprietary Windows-based IDE from my automation/control system vendor, the tabbed user interface no longer works correctly when running under Wine. Previously, the IDE displayed its editors and views as tabs within a single main window (similar to applications like Visual Studio Code). After the update, these tabs are now opened as separate top-level windows instead of being embedded as tabs in the main application window. This behavior only occurs when running the application with Wine. On native Windows systems, the IDE still behaves correctly and shows tabs as expected. Expected behavior: Editors and views should be displayed as tabs within the main IDE window, as before the update. Actual behavior: Each tab is opened as an individual window, breaking the intended tabbed workflow and making the IDE difficult to use. Regression: Yes. The tabbed interface worked correctly with earlier versions of the IDE under Wine. The issue appeared immediately after the vendor updated the application. Additional notes: The application is proprietary, so source code is not available. The issue seems related to how the updated IDE handles tabbed/docked windows or window embedding under Wine. Environment: Wine version: v11.1 Wine architecture: win64 / win32 Distribution: arch linux Desktop environment / window manager: kde plasma Application version: proprietary ide for control systems -- 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 7