DaisyUI makes tauri window freeze with no —verbose nor Rust Traceback

[AdamTmHun]

Describe the bug

Please read the whole thing. This issue is 100% with tauri or a dependency tauri is using, since DaisyUI works well in a regular web browser.

The problem only exists from Daisy UI version 4.0.0, the last v3 release on 3.9.4 works. According to the change logs, they started using a new color calculating format, OKLCH instead of HSL. One interesting line in the changelog is:

OKLCH colors are supported in Chrome/Edge 111+, Safari 15.4+, Firefox 113+

I am not sure if this effects tauri, and/or I can do anything to change this. I am also 99% sure that the new format causes the issue. I have a custom theme enabled, and when I use the default ones, it does not freeze, and this is justified by this line in the changelog:

For old browsers, daisyUI provides HEX fallback colors only for the default dark/light themes.

One interesting thing I noticed that the app freezes sometimes instantly, sometimes I can click around for even 10 seconds and use buttons (which already use the new format with the click animation), and it only freezes after that.

Im asking if anyone else had any problem related, or if there is a known way to fix this isuse.

Reproduction

Both the latest stable and beta versions of tauri have this issue. Anyone can try to replicate my problem following the Build instructions in this Github repo (I'm using arch linux with xorg, webkit2gtk. One friend confirms it doesnt work on fedora w/ wayland).

Expected behavior

Not freezing

Full tauri info output

Note: I am using the beta here, but it didn't work in stable either.

[✔] Environment
    - OS: Arch Linux Rolling Release X64
    ✔ webkit2gtk-4.1: 2.44.1
    ✔ rsvg2: 2.58.0
    ✔ rustc: 1.77.2 (25ef9e3d8 2024-04-09)
    ✔ cargo: 1.77.2 (e52e36006 2024-03-26)
    ✔ rustup: 1.27.0 (2024-03-12)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (default)
    - node: 20.12.2
    - pnpm: 9.0.5
    - yarn: 1.22.22
    - npm: 10.5.0

[-] Packages
    - tauri [RUST]: 2.0.0-beta.16
    - tauri-build [RUST]: 2.0.0-beta.13
    - wry [RUST]: 0.39.3
    - tao [RUST]: 0.27.1
    - @tauri-apps/api : not installed!
    - @tauri-apps/cli [NPM]: 2.0.0-beta.13

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../build
    - devUrl: http://localhost:5173/
    - framework: Svelte
    - bundler: Vite

Stack trace

No response

Additional context

No response

[FabianLars]

Can you try it in epiphany (also known as gnome web)? If it has the same issue it's a general webkitgtk upstream issue and not just tauri :/

[AdamTmHun]

Crap, it doesnt work with epiphany either

This upstream fix is going to take a long time right?

I also noticed that tauri v2 tires to use webkit2gtk 4.1, and tauri v1 an even older 2.x version, and the newest is 6.0. Why is that? (My issue doesnt work with 6.0 either epiphany confirms that, but im just curious)

[FabianLars]

4.0 is gtk3 and libsoup 2.4 (tauri v1) 4.1 is gtk3 and libsoup 3 (tauri v2) 6.0 is gtk4 and libsoup 3 (probably tauri v3) (Libsoup is the http client webkitgtk uses)

4.1 is still supported (iirc 4.0 kinda too but it has issues that can't be fixed with libsoup 2.4) and because the jump to gtk4 was too large (we use things that only work with gtk3) we went with 4.1 in v2

[FabianLars]

P.S. Most fixes should land in 4.1 and 6.0 for the time being. But yes, it may take a while :/

[AdamTmHun]

Good news - I found a fix. (I still cannot believe all this.)

Story

After writing this bug report, we thought all hope was lost. Then I discovered by looking at the node_modules of daisyUI and pasting a default theme as a custom theme, we can provide oklch colors into the custom theme instead of hex. And the theme I tried (it was lemonade) worked with a comination of hex and oklch colors. Then I started changing all of my custom theme's colors to oklch. I tested if it works after changing three colors of the nine, and it seemed to have worked. I changed all of them, it still worked. And then I was like wait a minute, all of them didnt require to be changed to oklch. I changed them one by one. Turns out, the problem was with the primary color, and all of them did not require to be changed. I experimented with different primary color hex values. And then I realized, we were so unlucky, we picked the single one color (there obviously might be other, unknown values) out of 16,777,216 possible hex colors, that caused this weird issue. If I just slightly change the shade, it already works with the hex values. I have zero idea why this is the case. I changed all colors to oklch, since the original primary I had works in that case. It's probbably safer to do so too.

I am very confused as why this happened. Let me know if you have any guesses, and if you know where I should file a bug report.

Fix

Convert all colors to oklch from your custom theme. Here is an online converter tool you can use.

Here is my theme for example:

{
// ...
  daisyui: {
    themes: [
      {
        'tagstudio-theme': {
            primary: 'oklch(67.99% 0.1155931375154364 200.6506960142565)',
            secondary: 'oklch(43.2% 0.211 292.76)',
            accent: 'oklch(94.91% 0 0)',
            neutral: 'oklch(36.23% 0.015 259.81)',
            'base-100': 'oklch(27.49% 0.019 258.37)',
            info: 'oklch(48.82% 0.217 264.38)',
            success: 'oklch(59.6% 0.127 163.23)',
            warning: 'oklch(76.86% 0.165 70.08)',
            error: 'oklch(57.71% 0.215 27.33)'
          }
        }
      ]
   }
}

PS: I hope I helped a random confused guy on the internet in the far future who couldn't find any resources to this.