tauri-apps/tauri · critical

not implemented

Error message

not implemented

What it means

In WebviewWindowBuilder::build, after creating a child webview the code dispatches to the runtime via `window.runtime()`, which is a RuntimeOrDispatch enum. Only the `Dispatch` variant supports `create_webview`, so every other variant (Application, Window) hits `unimplemented!()`. Panicking here means a child webview was requested in a context where the window handle holds something other than a runtime dispatcher.

Solutions

1. Ensure add_child/build is called on a WebviewWindow whose runtime() yields RuntimeOrDispatch::Dispatch (a real window dispatcher), not the app-level handle
2. Use the correct builder API: create child webviews from the window (WebviewWindowBuilder on the window) rather than from the application handle
3. Update Tauri — newer versions route all create_webview calls through a dispatcher-compatible path
4. If maintaining a fork, handle the Application/Window variants explicitly (obtain a dispatcher from them) instead of `unimplemented!()`

Example fix

// before
_ => unimplemented!(),
// after
RuntimeOrDispatch::Application(handle) => handle.create_webview(pending),
RuntimeOrDispatch::Window(window) => window.dispatcher().create_webview(pending),

if !matches!(window.runtime(), RuntimeOrDispatch::Dispatch(_)) {
  eprintln!("add_child requires a window dispatcher handle");
}

fn is_dispatcher(rt: &RuntimeOrDispatch<W>) -> bool {
  matches!(rt, RuntimeOrDispatch::Dispatch(_))
}

// This is a panic, not a Result. Call build() only on WebviewWindow instances (window handles), and catch process-level panics:
std::panic::catch_unwind(|| builder.build(window.clone()));

When it happens

Trigger: Calling WebviewWindowBuilder::add_child / build while the parent's runtime accessor resolves to RuntimeOrDispatch::Application or RuntimeOrDispatch::Window instead of Dispatch — e.g. creating a child webview from a context that is not a plain dispatchable window handle.

Common situations: Constructing multi-webview windows from an app handle rather than a window handle; mixing webview-window and window APIs on the wrong handle type; fork/custom runtime code returning a non-dispatch variant from runtime().

Related errors

• not implemented
• cannot use both `resources` and `resources_map`
• failed to canonicalize global API script path
• failed to get exe directory
• failed to parse plugin global API script paths

AI-assisted analysis of tauri-apps/tauri@460ec35447 (2026-09-18). Data as JSON: /api/errors/33fa802742e48a11. Report an issue: GitHub.

Appendix: source

Thrown at crates/tauri/src/webview/mod.rs:868

  /// Creates a new webview on the given window.
  #[cfg(desktop)]
  pub(crate) fn build(
    self,
    window: Window<R>,
    position: Position,
    size: Size,
  ) -> crate::Result<Webview<R>> {
    let app_manager = window.manager();

    let mut pending = self.into_pending_webview(&window, window.label())?;

    pending.webview_attributes.bounds = Some(tauri_runtime::dpi::Rect { size, position });

    let use_https_scheme = pending.webview_attributes.use_https_scheme;

    let webview = match &mut window.runtime() {
      RuntimeOrDispatch::Dispatch(dispatcher) => dispatcher.create_webview(pending),
      _ => unimplemented!(),
    }
    .map(|webview| {
      app_manager
        .webview
        .attach_webview(window.clone(), webview, use_https_scheme)
    })?;

    Ok(webview)
  }
}

/// Webview attributes.
impl<R: Runtime> WebviewBuilder<R> {
  /// Sets whether clicking an inactive window also clicks through to the webview.
  #[must_use]
  pub fn accept_first_mouse(mut self, accept: bool) -> Self {
    self.webview_attributes.accept_first_mouse = accept;
    self

View on GitHub (pinned to 460ec35447)