slint-ui/slint · error

the winit event loop runs inside the context that owns this…

Error message

the winit event loop runs inside the context that owns this backend

What it means

`SharedBackendData::context()` returns the `SlintContext` that owns the winit backend, stored as a weak reference. The event loop only ever runs while a live context exists, so if the weak upgrade fails this is an internal invariant violation and the code panics.

Solutions

1. Keep the `SlintContext` (and platform) alive for as long as the winit backend/event loop is used
2. Initialize the Slint platform before creating windows or touching backend internals
3. If hit inside the library, report a bug - this path should be unreachable from normal API use

Example fix

// before
let backend = get_backend();
drop(slint_context); // context freed
let ctx = backend.context(); // panics
// after
let ctx = slint_context.context(); // keep context alive first
let backend = get_backend();
let ctx = backend.context(); // ok

// keep a strong SlintContext for the lifetime of the app
let ctx = slint_context.clone(); // SlintContext handle held until process exit

std::panic::catch_unwind(|| backend.context())
    .map_err(|_| anyhow!("SlintContext dropped before backend use; keep platform alive"))?;

When it happens

Trigger: Calling code that resolves `SharedBackendData::context()` when the owning `SlintContext` has already been dropped (or before it was registered), i.e. backend internals running without the platform context alive.

Common situations: Holding a backend/event-loop handle after dropping the `SlintContext`; custom platform setups that drop the context while the winit loop is referenced; bugs in embedding order of context creation vs backend use.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

• context menus should always have a menu
• internal error: accesskit adapter must exist when window…
• spawn is called while the SlintContext is still alive
• a setter belongs to a field
• an identifier

AI-assisted analysis of slint-ui/slint@3a7e700487 (2026-09-16). Data as JSON: /api/errors/439c766333eb084e. Report an issue: GitHub.

Appendix: source

Thrown at internal/backends/winit/lib.rs:483

    is_wayland: bool,
    /// Desktop settings read from the XDG portal (cursor blink, appearance query).
    #[cfg(xdg_desktop_settings)]
    desktop_settings: xdg_desktop_settings::DesktopSettings,
    #[cfg(target_os = "ios")]
    #[allow(unused)]
    keyboard_notifications: ios::KeyboardNotifications,
    #[cfg(target_os = "ios")]
    #[allow(unused)]
    scene_lifecycle: ios::SceneLifecycle,
}

impl SharedBackendData {
    /// Panics if the backend is not bound: an event loop only runs inside a live context.
    pub(crate) fn context(&self) -> i_slint_core::SlintContext {
        self.context
            .get()
            .and_then(|ctx| ctx.upgrade())
            .expect("the winit event loop runs inside the context that owns this backend")
    }

    fn new(
        mut builder: EventLoopBuilder,
        renderer_name: Option<String>,
        requested_graphics_api: Option<RequestedGraphicsAPI>,
        allow_fallback: bool,
    ) -> Result<Self, PlatformError> {
        #[cfg(not(target_arch = "wasm32"))]
        use raw_window_handle::HasDisplayHandle;

        #[cfg(all(unix, not(target_vendor = "apple")))]
        {
            #[cfg(feature = "wayland")]
            {
                use winit::platform::wayland::EventLoopBuilderExtWayland;
                builder.with_any_thread(true);
            }

View on GitHub (pinned to 3a7e700487)