[Bug 58921] New: WebView2 does not work with Windows version setting 8.1 or newer
http://bugs.winehq.org/show_bug.cgi?id=58921 Bug ID: 58921 Summary: WebView2 does not work with Windows version setting 8.1 or newer Product: Wine Version: 10.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: felixhaedicke(a)web.de Distribution: --- Created attachment 79605 --> http://bugs.winehq.org/attachment.cgi?id=79605 webview.log (log created by WebView2) For testing WebView2, I am using my "SimpleWebView2Browser", see https://github.com/felixhaedicke/SimpleWebView2Browser for source code and binaries. Steps to get it running on a fresh wineprefix: * Install WebView2 runtime using the "Evergreen Standalone Installer" for x64 from Inst https://developer.microsoft.com/en-us/microsoft-edge/webview2 * Set Windows version to Windows 7 or 8. * Use my "SimpleWebView2Browser" binaries from https://github.com/felixhaedicke/SimpleWebView2Browser/releases/tag/v0.1 It is sufficient to set the Windows version for "msedgewebview2.exe" (which is part of the WebView2 runtime): wine reg add "HKEY_CURRENT_USER\Software\Wine\AppDefaults\msedgewebview2.exe" /v Version /t REG_SZ /d win8 It does not work with Windows version set to 8.1, 10 or 11. The problem is probably that WebView2 tries to use the DirectComposition API on Windows 8.1 or newer. Message in the WebView2 debug log: DCompositionCreateDevice failed: Not implemented. (0x80004001) The attached WebView2 debug log was captured using the WebView2 logging functions, which can be enabled using the WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS environment variable. Command line used to start the browser process, and to capture the attached logs: WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS="--enable-logging --v=1 --log-file=c:/webview.log" wine SimpleWebView2Browser.exe 2> wine-output.txt -- 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=58921 --- Comment #1 from Felix Hädicke <felixhaedicke(a)web.de> --- Created attachment 79606 --> http://bugs.winehq.org/attachment.cgi?id=79606 Wine console output The wine console output also shows messages about failed DCompositionCreateDevice calls: 01f0:fixme:dcomp:DCompositionCreateDevice3 00007FFFFEF26DB0, {5f4633fe-1e08-4cb8-8c75-ce24333f5602}, 00007FFFFE8FE428. 0314:fixme:dcomp:DCompositionCreateDevice 0000000000000000, {c37ea93a-e7aa-450d-b16f-9746cb0407f3}, 00007FC440FAE420. -- 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=58921 Eric Pouech <eric.pouech(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech(a)gmail.com --- Comment #2 from Eric Pouech <eric.pouech(a)gmail.com> --- There will be lots of missing bits to support native webview2. As chromium decides to use or not features based on Windows OS version, to get things properly working you'll need a bunch of things done: For Win10: - direct composition as you noted, - also sandboxing (including lots of bits in token & acl management) - GPU support - basically most of the FIXMEs from your log are a starting point - ... So I don't expect this to be resolved before a long time given the list of missing features. Side note: The list above comes for testing chromium builds, not native webview2/ I'm not sure EULA for installing native webview2 permits to run it on Wine, so I will not test it myself. -- 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=58921 eff3ctsb0t(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eff3ctsb0t(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58921 Adam Adams <adam@adam-adams.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adam@adam-adams.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58921 --- Comment #3 from Adam Adams <adam@adam-adams.com> --- This bug also seems to be a massive roadblock in getting the newer versions of Steinberg Cubase (12 and up) from working on Wine, because the splashscreen/Steinberg Hub make heavy use of WebView2. One of the lines I get in debug logs is: 0024:fixme:dcomp:DCompositionCreateDevice 00000000014C6EC0, {c37ea93a-e7aa-450d-b16f-9746cb0407f3}, 00000000002AF6C8. Cubase 12 is more forgiving, because the implementation wasn't as spread as it is in the newer versions. I still need to document all of but, but would any other logs help here? I'm more than happy to provide. -- 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=58921 Zeb Figura <z.figura12@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stan@stanstaykov.com --- Comment #4 from Zeb Figura <z.figura12@gmail.com> --- *** Bug 59370 has been marked as a duplicate of this bug. *** -- 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=58921 Zeb Figura <z.figura12@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |robertthesable@gmail.com --- Comment #5 from Zeb Figura <z.figura12@gmail.com> --- *** Bug 59431 has been marked as a duplicate of this bug. *** -- 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=58921 brandow <brandowlucas@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |brandowlucas@gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58921 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source URL| |https://github.com/felixhae | |dicke/SimpleWebView2Browser -- 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=58921 Robert T <robertthesable@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|robertthesable@gmail.com | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58921 tenxcode@outlook.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tenxcode@outlook.com --- Comment #6 from tenxcode@outlook.com --- I can reproduce a related blank embedded-surface failure on Apple Silicon macOS, independent of any specific host application. A minimal C# WinForms form containing Microsoft.Web.WebView2 1.0.2957.106 initializes successfully, but the WebView2 child remains white and CapturePreviewAsync() produces a zero-byte PNG. Environment: - Apple M4 (arm64), macOS 26.5.2 (25F84) - Wine Staging 11.14, unmodified prebuilt package - Microsoft Edge WebView2 Runtime 150.0.4078.105 - Disposable 64-bit prefix with the runtime installed; no Windows DLL overrides Steps: 1. Build/run the attached direct WinForms reproducer in the disposable prefix with WINEDEBUG=+d3d11,+dxgi,+dcomp,+d2d,+winediag. 2. Wait for WebView2 initialization and navigation to its solid blue test page. Expected: blue HTML content is visible and CapturePreviewAsync() writes a non-empty PNG. Actual: initialization reports success, the embedded child surface is white, and the PNG is empty. The attached complete terminal trace shows WebView2 GPU-process FL12.1..FL10.0 requests being rejected, then DirectComposition reaching IDCompositionVisual::SetContent(). At that point Wine's D2D path calls ID3D11Device1::CreateDeviceContextState with one requested level (FL10.0); wined3d rejects it and dcomp logs “Failed to create a D2D device context, hr 0x80004005.” GL_INVALID_FRAMEBUFFER_OPERATION is also logged from wined3d/context_gl.c:2246. A separate control launched with --disable-gpu --disable-gpu-compositing --disable-gpu-rasterization still reached the same DComp/D2D FL10 failure, so those browser flags are not a workaround here. Source correlation: Wine 11.14 dlls/d2d1/device.c requests D3D_FEATURE_LEVEL_10_0 for the context state and compiles built-in shaders as vs_4_0/ps_4_0. Thus lowering the requested level alone is not a valid fix. Attachments: - WebView2WinFormsProbe.cs: minimal reproducer source - wine-staging-webview2-trace.log: complete terminal output for the failing run -- 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=58921 --- Comment #7 from tenxcode@outlook.com --- Created attachment 81605 --> http://bugs.winehq.org/attachment.cgi?id=81605 Complete Wine Staging 11.14 terminal trace: WebView2 DirectComposition/D2D FL10 failure on Apple M4 macOS -- 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=58921 --- Comment #8 from tenxcode@outlook.com --- Created attachment 81606 --> http://bugs.winehq.org/attachment.cgi?id=81606 Minimal WinForms + Microsoft.Web.WebView2 reproducer source for the blank DirectComposition surface -- 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=58921 Wehrwolfmann <wehrwolfmann@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wehrwolfmann@gmail.com --- Comment #9 from Wehrwolfmann <wehrwolfmann@gmail.com> --- The DirectComposition part of this still reproduces with wine-11.15 (vanilla, 64-bit, clean prefix, no DLL overrides, no DXVK), with the WebView2 runtime 151.0.4129.78 installed in the prefix. One more affected application, in case it helps triaging: Razer Axon 2.9.1.0, whose entire UI is WebView2. The per-application override from comment #0 (Version=win7 for msedgewebview2.exe only, the rest of the prefix staying on win10) still works on 11.15, so the workaround has not rotted. I have attached to bug 55432 a ~90 line repro that needs neither WebView2 nor any application: it only performs the DirectComposition call Chromium makes at startup once the reported Windows version is >= 8.1. The D3D11 device and its IDXGIDevice are created fine; only DCompositionCreateDevice/2/3 fail, all three with E_NOTIMPL, which matches dlls/dcomp/device.c in current master. Since the DirectComposition part of this bug is the same hole as bug 55432, it may be worth marking this one as depending on 55432 so the dcomp work is tracked in one place. -- 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=58921 --- Comment #10 from Wehrwolfmann <wehrwolfmann@gmail.com> --- Update to my previous note: on wine-staging 11.15 the per-application Version=win7 override for msedgewebview2.exe is no longer needed. Measured on Razer Axon 2.9.1.0 (WebView2 runtime 151.0.4129.78), the same prefix used with both builds, override removed, prefix reporting Windows 10: vanilla 11.15 -- blank window, GPU process restart loop, nine processes each logging fixme:dcomp:DCompositionCreateDevice / ...Device3 staging 11.15 -- UI renders completely, no restart loop which is consistent with the DirectComposition measurements in bug 55432: the staging dcomp patchset is what removes the need for the override. On vanilla the workaround from comment #0 is still required. -- 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=58921 --- Comment #11 from brandow <brandowlucas@gmail.com> --- In my case, using the staging dcomp-DCompositionCreateDevice2 patchset + msedgewebview2.exe set to win10 still makes NinjaTrader's embedded "Chat" WebView2 render completely black. WebView2 itself is running since the right click context menu and the separate DevTools window render correctly. Only the embedded Chat content page stays black. Just using the staging patchset will also loop and memory hog while logging those errors: 05b0:fixme:dcomp:DCompositionCreateDevice3 0000000000E59230, {5f4633fe-1e08-4cb8-8c75-ce24333f5602}, 000000000091E418. 05b0:fixme:dcomp:device_QueryInterface {4ca97a18-cbfd-4b0d-89e1-f7fa86d8d63e} not implemented, returning E_NOINTERFACE I'm not sure if those errors are directly causing the loop/memory hog though. Nevertheless, I used the github.com/giang17/wine DirectComposition fork with a local change hack I did (https://github.com/BrandowLucas/wine-dcomp/commit/159ce338f82aa820cd7bc65fe2...), and it now renders NinjaTrader's embedded Chat WebView2 successfully with win10/DComp. With WebView2 109.0.1518.140, the Win7 workaround also wouldn't do it in my case. The embedded window only worked when using win10 and the DComp implementation from the custom fork. I didn't bother checking whether it is possible to fix WebView2's legacy Windows 7 rendering path without DComp. -- 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=58921 --- Comment #12 from Wehrwolfmann <wehrwolfmann@gmail.com> --- In reply to comment #11: the black embedded panel reproduces here too, and it reproduces without WebView2 or NinjaTrader, so it can be tested directly. I wrote a small probe that walks the whole path by hand: create the DComp device, CreateSwapChainForComposition, paint one red frame, SetContent, SetRoot, Commit, then read a pixel back from the screen. Three variants of the target window, wine-staging 11.17, fresh 64-bit prefix, win10, Xvfb, llvmpipe: A. WS_EX_NOREDIRECTIONBITMAP only -> red, frame is visible B. WS_EX_LAYERED|WS_EX_NOREDIRECTIONBITMAP -> black, frame never arrives C. as B, plus SetLayeredWindowAttributes(LWA_ALPHA) -> red again All calls return S_OK in every variant; the only fixmes are the known semi-stubs of Commit and visual_SetContent. That is the difference. The staging patchset presents by blitting the front buffer into GetDCEx(target->hwnd) once per frame. That reaches the screen for an ordinary window and for a layered window driven by SetLayeredWindowAttributes, but not for a layered window driven by UpdateLayeredWindow, which is what an embedded rootless panel uses. It matches comment #11 exactly: the separate top-level windows (DevTools, context menu) render, the embedded Chat panel does not. One false trail worth removing: the QI failure on {4ca97a18-cbfd-4b0d-89e1-f7fa86d8d63e} and DCompositionCreateDevice3 returning E_NOINTERFACE are not the cause. I logged the same E_NOINTERFACE on 2026-08-14 while a full WebView2 UI was rendering correctly (comment #10), and the fork that works for the reporter fails that QI as well. The IID is not in dcomp.idl, not in the public SDK header set, and not among the undocumented interfaces the patchset answers. For completeness on vanilla: 11.17 and 11.18 still return E_NOTIMPL from all three DCompositionCreateDevice* entry points, so this is a staging-only discussion for now. -- 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=58921 --- Comment #13 from Wehrwolfmann <wehrwolfmann@gmail.com> --- Follow-up to comment #12: a local experiment points at where the fix goes. When the presenter sees a target window that has WS_EX_LAYERED but no layered attributes (GetLayeredWindowAttributes fails on it) and hands the frame to UpdateLayeredWindow with ULW_ALPHA instead of drawing into GetDCEx, variant B turns red on 11.18 with the staging patchset, while A and C stay red as before. Deciding this once, when the target is bound to the window, is enough; nothing has to be polled per frame. I am not posting a patch, only the observation, so whoever maintains the patchset can do it their way. -- 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=58921 Giang Nguyen <nen24t@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nen24t@gmail.com --- Comment #14 from Giang Nguyen <nen24t@gmail.com> --- Regarding comment 11: the DirectComposition fork mentioned there (https://github.com/giang17/wine) now does what the local change linked in comment 11 does, presenting the target with UpdateLayeredWindow, with a narrower condition: https://github.com/giang17/wine/commit/1095c1f4dba (branch d2d1-dcomp-11.0; on d2d1-dcomp-11.19 as 696859799d6) It applies to a visual tree without content on its root visual whose target is an in-process top-level window with WS_EX_LAYERED | WS_EX_NOREDIRECTIONBITMAP, no layered attributes and no non-client area. An application-free probe of exactly that case left the X window unmapped before the change; with it, the composed image is shown, per-pixel alpha included. NinjaTrader itself was not tested. A run of the chat panel on that build without the local change would show whether this covers 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.
http://bugs.winehq.org/show_bug.cgi?id=58921 --- Comment #15 from Giang Ng <nen24t@gmail.com> --- Follow-up to comment 14: 1095c1f4dba does not cover NinjaTrader 8's chat window. Measured layout (WebView2 runtime 155.0.4283.45, prefix on Windows 10): the chat is a WPF top-level with WS_EX_LAYERED and no layered attributes, so it is painted with UpdateLayeredWindow; inside it Static > Chrome_WidgetWin_0 > Chrome_WidgetWin_1 > "Intermediate D3D Window" (ex-style 0x00280024, owned by a WebView2 process, not by NinjaTrader), and that child is the DirectComposition target. 1095c1f4dba is limited to top-level targets; with it the chat still showed only the WPF background. For this layout the frame was lost in wineserver and winex11, not in the presenter. For a surface created by UpdateLayeredWindow, apply_window_pos() reports a 1x1 surface rect (dummy_surface.rect, dlls/win32u/window.c), and get_visible_region() (server/window.c) clips the visible region of every descendant with it, so a blit into the child's DC reaches a single pixel. That part is upstream code (wine-11.19 has it), so a blit into GetDCEx() of such a child meets the same clip. Presenting the child itself with UpdateLayeredWindow, as comment 13 describes for a layered target without attributes, was measured without visible effect on a child target before the fix below (application-free probe of this layout, 20 of 20 samples). Fixed in the fork by https://github.com/giang17/wine/commit/d54c12ac8a8 and https://github.com/giang17/wine/commit/6d09e40424a (branch d2d1-dcomp-11.0; on d2d1-dcomp-11.19 as d219e688536 and c3c3d74a571): a WS_EX_NOREDIRECTIONBITMAP child of another process keeps the client area of its layered ancestor, and the layered top-level's surface flush leaves that child out. On Windows 10 the probe (DComp child of a second process inside a top-level repainted with UpdateLayeredWindow) shows the child's tree over the layered image; Wine now does the same for four extended-style variants of the child, with and without content on the root visual. NinjaTrader 8's chat renders its page, without the local change from comment 11. -- 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=58921 --- Comment #16 from Wehrwolfmann <wehrwolfmann@gmail.com> --- I ran both layouts on the fork's d2d1-dcomp-11.19: 64-bit, fresh prefix, win10, Xvfb, llvmpipe, 20 screen samples per run. Comment 14: WS_POPUP top-level, client == window, ex-style 0x00280000, no layered attributes, swapchain on a child visual, root visual empty. At 882a4d488d4 (parent of 696859799d6) nothing is shown, the X window is unmapped. At cb9ab98273d and c3c3d74a571 it is shown, 5 runs of 5, and the log has the UpdateLayeredWindow line. Comment 15: process 1 owns a WS_POPUP top-level with WS_EX_LAYERED only and repaints it blue with UpdateLayeredWindow every 200 ms; process 2 creates a WS_CHILD in it and composes red. Child ex-styles 0x00280024, 0x00280000, 0x00200000, 0x00200020, swapchain on the root or on a child visual. At c3c3d74a571 it depends on where the child sits. With one plain child window between it and the layered top-level all eight are red (blue at cb9ab98273d). Created directly in the layered top-level all eight stay blue; when that child covers the whole window, exactly one pixel is red, the top-left one. The probe from comment 12 is red in A, B and C at both commits, by the path the fork had before (framed window, swapchain on the root visual). Razer Axon paints fully at c3c3d74a571. Nothing here was run on Windows. -- 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=58921 --- Comment #17 from Giang Ng <nen24t@gmail.com> --- Thanks for the precise re-measurement in comment 16: the single red pixel at the top-left pointed straight at the cause. The observations for a child created directly in the layered top-level (blue; with the child covering the whole window, red only at the top-left pixel; red with a plain window in between) reproduce with an application-free probe of that layout when the target window's class has CS_PARENTDC and the window has neither WS_CLIPSIBLINGS nor WS_CLIPCHILDREN. Without CS_PARENTDC, or with WS_CLIPSIBLINGS added, the same layout was red on d2d1-dcomp-11.19 before the change below. For such a window GetDC() uses DCX_PARENTCLIP, and that branch of get_visible_region() (server/window.c) starts from the parent's client rect intersected with the parent's surface rect, which for an UpdateLayeredWindow() top-level is the one-pixel rect. 6d09e40424a (c3c3d74a571 on d2d1-dcomp-11.19) exempted only the ancestor loop further down from that rect, not this branch. With a plain window in between, the parent clip is taken from that window instead. Fixed in https://github.com/giang17/wine/commit/4654170ab03 (branch d2d1-dcomp-11.0; on d2d1-dcomp-11.19 as e7a6a9fc572). With CS_PARENTDC on the target class: blue in 8 of 8 child style and content combinations before (d2d1-dcomp-11.19), red in 8 of 8 after on both branches; a child covering part of the window is red on exactly its own area. On the Windows side, which comment 16 left open: Windows 10 shows the tree of a WS_EX_NOREDIRECTIONBITMAP child of a second process over an UpdateLayeredWindow() top-level, with and without CS_PARENTDC on the child's class. -- 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=58921 --- Comment #18 from Wehrwolfmann <wehrwolfmann@gmail.com> --- Confirmed at e7a6a9fc572 (d2d1-dcomp-11.19), setup as in comment 16. The child created directly in the layered top-level is now red: 0x00280024, swapchain on the root or on a child visual, 5 runs of 5 each; the other three ex-styles, one run each. Covering part of the window it is red on exactly its own 300x200 area; covering all of it, red all over (5 runs). The condition matches: my target is a system "Static" window, class style 0x88 (CS_PARENTDC), no clip styles. At c3c3d74a571 a class without CS_PARENTDC, or WS_CLIPSIBLINGS or WS_CLIPCHILDREN on the window, was already red. Unchanged: comment 14 layout, the child behind a plain window, the probe from comment 12. Razer Axon paints fully at this commit too, as at c3c3d74a571. Nothing here was run on Windows. -- 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.
participants (2)
-
WineHQ Bugzilla -
WineHQ Bugzilla