[bug] window.documentPictureInPicture.requestWindow throws "no window" error

[bra1n]

Describe the bug

It seems like a recent Tauri update broke the documentPictureInPicture interface for Tauri apps on Windows 10. With older Tauri versions, I was able to open PiP windows just fine (and it still works on Edge itself), but the latest Tauri version for some reason broke this support.

Reproduction

1. create a Tauri app with npm create tauri-app@latest (vanilla JS frontend)
2. add this code to the greet() example function:

await window.documentPictureInPicture.requestWindow({
  width: 600,
  height: 400,
});

3. click on the "Greet" button

Expected behavior

A new sub-window of the current Tauri window should have opened, like this:

This works if I open the Tauri dev server in a local Edge instance.

Full tauri info output

> tauri-app@0.1.0 tauri
> tauri info


[✔] Environment
    - OS: Windows 10.0.19045 x86_64 (X64)
    ✔ WebView2: 141.0.3537.99
    ✔ MSVC: Visual Studio Community 2022
    ✔ rustc: 1.86.0 (05f9846f8 2025-03-31)
    ✔ cargo: 1.86.0 (adf9b6ad1 2025-02-28)
    ✔ rustup: 1.28.1 (f9edccde0 2025-03-05)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 25.1.0
    - npm: 11.6.2

[-] Packages
    - tauri 🦀: 2.9.2
    - tauri-build 🦀: 2.5.1
    - wry 🦀: 0.53.5
    - tao 🦀: 0.34.5
    - @tauri-apps/api  ⱼₛ: not installed!
    - @tauri-apps/cli  ⱼₛ: 2.9.2

[-] Plugins
    - tauri-plugin-opener 🦀: 2.5.2
    - @tauri-apps/plugin-opener  ⱼₛ: not installed!

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../src

Stack trace

main.js:7 
 Uncaught (in promise) InvalidStateError: Failed to execute 'requestWindow' on 'DocumentPictureInPicture': Internal error: no window
    at greet (main.js:7:41)
    at HTMLFormElement.<anonymous> (main.js:20:5)
greet	@	main.js:7
(anonymous)	@	main.js:20

Additional context

This worked on previous Tauri versions without issues.

[FabianLars]

This sounds like another unforeseen use-case that #13876 broke. Not a fan of the breakage but the new behavior is what has been the intention so i doubt it'll be reverted. You can fix this by using the new api, simplest example:

#[cfg_attr(mobile, tauri::mobile_entry_point)]
pub fn run() {
    tauri::Builder::default()
        .setup(|app| {
            let _ = tauri::WebviewWindow::builder(
                app.handle(),
                "window-label",
                tauri::WebviewUrl::App(std::path::PathBuf::from("/")),
            )
            .on_new_window(|_url, _features| {
                // Ideally you do something with url and features to evaluate if you want to allow the window.
                tauri::webview::NewWindowResponse::Allow
            })
            .build();

            Ok(())
        })
        .plugin(tauri_plugin_opener::init())
        .invoke_handler(tauri::generate_handler![])
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

[bra1n]

Thanks @FabianLars, but when I copy your code into the example Tauri app, it now opens the sample app twice when I run npm run tauri dev, where one instance has a working documentPictureInPicture window and the other does not. How do I prevent two Tauri main windows from spawning?

[bra1n]

That said, this does not actually "fix" this issue, as a PictureInPicture window is quite a bit different from a regular webview, in a few key places:

• it is always on top of other windows
• it doesn't show an address bar
• it has a "return to parent" button in the title bar
• it fires an event for the parent window when it is closed

The workaround you shared seems to just create a standard browser pop-up, which is serviceable but quite different from what was available before.

[FabianLars]

but when I copy your code into the example Tauri app, it now opens the sample app twice when I run npm run tauri dev, where one instance has a working documentPictureInPicture window and the other does not. How do I prevent two Tauri main windows from spawning?

You'd have to remove the main window from tauri.conf.json or add create: false and use from_config in rust.

That said, this does not actually "fix" this issue, as a PictureInPicture window is quite a bit different from a regular webview, in a few key places:

Hmmm, i think we'll need a new enum variant like Unmanaged to get that behavior back. Edit: maybe not, misread the code and Allow should be the old behavior.

[FabianLars]

With older Tauri versions, I was able to open PiP windows just fine

Any idea which versions those were? I can only get the plain popup window without the extras you listed even when downgrading to 2.0

[bra1n]

With older Tauri versions, I was able to open PiP windows just fine

Any idea which versions those were? I can only get the plain popup window without the extras you listed even when downgrading to 2.0

I can confirm that Tauri 2.4.0 does not have the above problem yet. Edit: unfortunately I don't know when the fancy pop-up worked last, but 2.4.0 already had the plain one, true. Sorry if I was unclear about what "working" meant, I was referring to the option to have a pop-out at all there, without the extra Rust code.

[FabianLars]

fair.

i think webview2 simply doesn't support this. Even if i remove all of our WindowRequested handling (using wry directly) and hence letting webview2 do its thing i only get basic popup windows.
What is weird is that there seems to be no discussion in https://github.com/MicrosoftEdge/WebView2Feedback/issues/ about anything remotely related 🤔

[bra1n]

Gotcha, thanks for the explanation! It's better than nothing, I guess and I was able to adapt your example code from above to this, so it's now working again as it was before, after setting create: false in the tauri.conf.json:

      .setup(|app| {
        let _ = tauri::WebviewWindowBuilder::from_config(
          app,
          app.config().app.windows.get(0).unwrap(),
        )
        .unwrap()
        .on_new_window(|_url, _features| {
            // Ideally you do something with url and features to evaluate if you want to allow the window.
            tauri::webview::NewWindowResponse::Allow
        })
        .build();
        Ok(())
      })

Unfortunately I'm not experienced enough with the WebView internals to be able to report anything there, I was just surprised that it worked on Edge properly, but didn't work with Tauri.