Activity

1. aniruddhaadak80

   self-assigned this

   on Nov 4, 2026
2. aniruddhaadak80

   added 7 commits that reference this issue on Nov 4, 2026

   fix(desktop): Linux window no longer stays black at first start (#10)

   ...

   0d3c530

   test(desktop): build the app and check it starts with a real window o…

   ...

   fc72a6b

   test(desktop): start test finds the running app by its process name a…

   ...

   79256aa

   docs: before and after screenshots for issue #10

   ...

   1d5ef72

   fix: start fallback title is not a page heading (#10)

   ...

   e90f3c3

   test(desktop): when a start fails, try other graphics settings and sa…

   ...

   ff6e25d

   test(desktop): skip Wayland on Ubuntu 22.04 in the start test (#10)

   ...

   bddde91
3. aniruddhaadak80 commented on Nov 4, 2026

   

   aniruddhaadak80

   on Nov 4, 2026 – with Hark

   Owner

   More actions

   Thanks for the report and the terminal output. I can confirm it, and it is fixed on main.

   What caused it

   On Linux, OpenFile draws its window with WebKitGTK. Since version 2.42, WebKitGTK draws pages through a DMA-BUF renderer that fails with some GPU drivers and compositors (NVIDIA most often, also some Mesa and Wayland setups). When it fails, the page is never drawn and the window keeps its black background colour. The WebProcess didn't exit as expected line is the web process that got stuck there.

   The AppImage is hit hardest because it carries its own copy of WebKitGTK. I reproduced it in CI: the 1.2.0 AppImage, started with no workarounds, stays empty on Fedora, Debian, Arch, Ubuntu 22.04 and Ubuntu 24.04, on X11 and on Wayland. Our old CI check set WEBKIT_DISABLE_DMABUF_RENDERER=1 for itself, which is why it did not catch this. The .rpm draws fine on CI machines (they have no GPU), so on your machine the GPU driver is the trigger for the .rpm. The same fix covers both.

   The fix

   • Commit 0d3c530 (main.rs, lines 52 to 140): on Linux the app turns off the DMA-BUF renderer unless you set the variable yourself, and on NVIDIA with Wayland it also sets __NV_DISABLE_EXPLICIT_SYNC=1.
   • main.rs, lines 473 to 492 and lines 535 to 539: if the window still has not loaded after 30 seconds, OpenFile restarts once in safe graphics mode (no GPU compositing) and remembers that.
   • index.html, lines 87 to 93: when the app code cannot load, the window shows a message with a Try again button instead of staying empty.
   • Commits fc72a6b, 79256aa and bddde91 add a CI check that builds the app and starts it with no workarounds on Ubuntu, Fedora, Debian and Arch (X11 and Wayland), Windows and macOS, and fails on a blank window. Latest run, all green.

   Before and after, Fedora on Wayland, AppImage, no workarounds set:

   

   The fixed .rpm on Fedora Wayland: screenshot

   Workaround for 1.2.0

   # .rpm
   WEBKIT_DISABLE_DMABUF_RENDERER=1 openfile
   # AppImage
   WEBKIT_DISABLE_DMABUF_RENDERER=1 ./OpenFile-linux-x86_64.AppImage

   If the window is still empty, add WEBKIT_DISABLE_COMPOSITING_MODE=1 as well. To keep it for the menu launcher, copy the OpenFile .desktop file from /usr/share/applications to ~/.local/share/applications and change its Exec= line to Exec=env WEBKIT_DISABLE_DMABUF_RENDERER=1 openfile %U. More in the troubleshooting guide.

   Which version

   The fix will ship in the next desktop release, 1.2.1. I will keep this issue open until that build is out. Could you try the workaround above now and tell me if the window draws? Your GPU and driver (for example the output of lspci -k | grep -A3 VGA) would also help, in case your setup needs safe graphics mode.
4. hhlp commented on Nov 4, 2026

   

   hhlp

   on Nov 4, 2026

   Author

   More actions

   Workaround for 1.2.0

   .rpm

   WEBKIT_DISABLE_DMABUF_RENDERER=1 WEBKIT_DISABLE_COMPOSITING_MODE=1 openfile

   same result

   lspci -k | grep -A3 VGA
   2d:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 730] (rev a1)
   Subsystem: Micro-Star International Co., Ltd. [MSI] Device 8a9f
   Kernel driver in use: nouveau
   Kernel modules: nouveau

   Regards.,
5. aniruddhaadak80

   assigned

   Copilot

   on Nov 11, 2026
6. Copilot

   linked a pull request that will close this issuePrevent Linux first-start black window by hardening WebKitGTK startup path #12on Nov 11, 2026
7. aniruddhaadak80

   added a commit that references this issue on Nov 11, 2026

   docs: issue #10 screenshots, fixed build in standard and software mod…

   ...

   18e0f5d
8. aniruddhaadak80 commented on Nov 11, 2026

   

   aniruddhaadak80

   on Nov 11, 2026 – with Hark

   Owner

   More actions

   Thanks for testing, and for the lspci output. That explains it: your GeForce GT 730 runs on nouveau, and nouveau's OpenGL can hang WebKitGTK's web process even with the DMA-BUF renderer and GPU compositing both turned off. That is why the 1.2.0 workaround still gave you an empty window.

   Try this now on 1.2.0 (draws without the GPU at all, every tool works the same, scrolling is a little slower):

   WEBKIT_DISABLE_DMABUF_RENDERER=1 WEBKIT_DISABLE_COMPOSITING_MODE=1 LIBGL_ALWAYS_SOFTWARE=1 WEBKIT_SKIA_ENABLE_CPU_RENDERING=1 openfile

   The fix: #13

   • linux_gpu.rs: when nouveau drives the only GPU (read from /sys/class/drm/card*/device/driver), OpenFile starts in software mode with the variables above. Laptops with an Intel or AMD GPU beside nouveau keep hardware drawing.
   • index.html and main.rs: the start check now waits for the first frame on screen instead of the page load, because a page can load and still draw nothing. With no frame after 30 s, OpenFile restarts one mode up (standard, safe, software) and remembers it. If even software mode draws nothing, it offers to open the same tools in your browser instead of leaving a black window.
   • OPENFILE_SAFE_GPU=2 starts in software mode by hand, OPENFILE_GPU=1 keeps the WebKitGTK defaults.

   Tested in CI (run, all 25 jobs green): the app is built from the PR and started with no workarounds on Ubuntu 22.04 and 24.04, Fedora, Debian and Arch, on X11 and Wayland, as AppImage, .deb and .rpm. Every Linux run must now report its first frame drawn and also draw in software mode. Windows 2022 and 2025 and macOS (Apple silicon and Intel) pass too, plus unit tests for the nouveau check.

   Fedora on Wayland, the fixed .rpm in standard mode and in software mode (the mode your machine will start in):

   

   CI machines have no NVIDIA card, so your hardware is the real test. Could you run the command above and say whether the window draws?