UI Rendering Halts After Menu Interaction on Windows 11

[781226451]

Bug Description

1. What is the bug?

Platform-Specific Rendering Freeze: On Windows 11, interacting with the menu bar (opening/closing menus) causes UI components (like ProgressIndicator) to stop visual updates despite continued property changes. Components only refresh after window resize/minimize-restore actions.

2. Expected vs Actual Behavior

Expected	Actual
UI components update continuously during/after menu interactions	Visual freeze after menu interaction - progress bar stops moving
No user intervention required for rendering	Requires manual window resize/minimize-restore to resume rendering
Consistent behavior across platforms	Windows-specific bug (macOS 13.5 unaffected)
UI reflects real-time data changes	Visual layer desync - data updates continue (confirmed via logs)

3. Steps to Reproduce

3.1 Environment Setup:

• Windows 11 Pro 24H2 (Simplified Chinese)
• Rust 1.87.0 (x86_64-pc-windows-msvc), Slint 1.11.0
• AMD Ryzen 9 9900X CPU
• NVIDIA GeForce RTX 4090 (Driver: 576.02)

3.2 Run Application:

Execute provided code sample

3.3 Initial Observation:

Progress bar increments by 0.05 every second (normal)

3.4 Console logs progress:

progress: 0.00 → progress: 0.05 → ...

3.5 Trigger Bug:

Click "Settings" menu (open/close without selecting items)

3.6 Observe Failure:

Progress bar visually freezes at last value Console continues logging (e.g., progress: 0.65, progress: 0.70)

3.7 Workaround Verification:

Resize window OR minimize → restore → progress bar jumps to current value

Reproducible Code (if applicable)

slint::slint!(
    import { ProgressIndicator } from "std-widgets.slint";
    export component MainWindow inherits Window {
        max-width: 400px;
        max-height: 100px;
        callback request-open();
        MenuBar {

            Menu {
                title: @tr("Settings");

                MenuItem {
                    title: @tr("Open");
                }
            }

        }

        in-out property<float> progress-value <=> progress-bar.progress; // 只暴露 progress
        progress-bar := ProgressIndicator {
            width: 90%;
            height: 20px;
            progress: 0.0;
        }
    }
);

fn main() {
    let ui = MainWindow::new().unwrap();

    let ui_handle = ui.as_weak();

    let bg_task = std::thread::spawn(move || {
        let mut progress = 0.0;

        while progress <= 1.01 {
            std::thread::sleep(std::time::Duration::from_secs(1));
            let ui_handle_clone = ui_handle.clone();

            slint::invoke_from_event_loop(move || {
                let ui = ui_handle_clone.upgrade().unwrap();

                ui.set_progress_value(progress);

                println!("progress: {}", progress);
            })
            .unwrap();

            progress += 0.05;
        }
    });
    
    ui.run().unwrap();
    drop(bg_task);
}

Environment Details

• Slint Version: 1.11.0
• Platform/OS: Windows 11 Pro 64-bit (24H2, Simplified Chinese)
• Programming Language: Rust
• Backend/Renderer: default in Windows 11

Product Impact

No response

[ogoffart]

Thanks for the bug report.

Would it be possible for you to provide a video or screencast showing the bug? This would help figuring out what component is responsible.

[781226451]

https://github.com/user-attachments/assets/256eb2a2-713c-42a7-b532-2d65a012340e

Note: The progress bar freezes on menubar click (00:05, 00:11) while console output continues uninterrupted. This locked state persists until either window resizing (00:16) or a minimize-restore operation (00:08) is performed. The program was executed on a clean Windows 11 Pro 24H2 installation (Simplified Chinese version).

[npwoods]

This issue, especially the part about window resizing unfreezing the UX, sounds a lot like this issue

[npwoods]

@781226451 i'm curious if this trick (from the previous issue) unhalts the UX?

with_winit_window(|x| x.request_redraw());

[781226451]

The issue was resolved immediately after switching to the Qt backend (Qt 6.8.3, MSVC build), with no code changes required.

Even after adding the request_redraw function to the original code with the default backend (winit), the issue persisted. The modified code is as follows:

slint::invoke_from_event_loop(move || {
    let ui = ui_handle_clone.upgrade().unwrap();
    ui.set_progress_value(progress);
    ui.window().request_redraw();  // the new line
    println!("progress: {}", progress);
}).unwrap();

This issue may originate from the winit backend, as do other similar issues such as #5863. @npwoods

The video below demonstrates the execution progress using the Qt backend, confirming that the halt issue has been resolved.

https://github.com/user-attachments/assets/d118feab-32c4-460f-8c7b-9b205b8aefe3

[tronical]

Another trivial way to reproduce the issue:

cargo run -p slint-viewer -- examples\gallery\gallery.slint

Observe how the indeterminate progress indicator animation stops while a menu from the menubar is open.

[tronical]

I can reproduce this straight on muda itself, and I've filed an issue there: https://github.com/tauri-apps/muda/issues/310 . That said, this might still be a winit issue.

[781226451]

In version 1.13.0, clicking the "Settings" Menu still causes the progress indicator to freeze. The update cycle is only resumed when the window loses and regains focus (e.g., by clicking away to another application and then back) or by clicking the "Open" Menu Item. This behavior is a significant change from versions 1.12.1 and earlier, where the progress bar would remain permanently frozen even after these actions. @tronical @ogoffart

[martgoodall]

not sure if i have the same issue but on windows 11, using c++ and latest slint 1.14,, it just doesnt work.

The windows frame is 100% replaced by the MenuBar (loosing close/max/min) and the icon of the MenuBar has a transparent background (see attached screenshot).

The same slint file works as expected on linux.

export component HomeWindow inherits Window {

MenuBar {

    Menu {

        title: "X";

        MenuItem {

            title: "Save All";
            activated => { callbackButtonMenuClickedSaveAll(); }
        }

        MenuItem {

            title: "Log Out";
            activated => { callbackButtonMenuClickedLogOut(); }
        }
    }
}

callback callbackButtonMenuClickedSaveAll();
callback callbackButtonMenuClickedLogOut();

}

[781226451]

It is recommended to explicitly set the width and height for window components in Slint 1.14. @martgoodall

[martgoodall]

i appreciate the comment/suggestion and added width and height to the window, but it did not resolve the issue on Windows 11/Slint with c++