Describe the bug
Creating a new window from the AppHandle struct with the create_window function results in a blank window on Windows.
Example:
#[tauri::command]
fn spawn_window(app: tauri::AppHandle) {
let external_url = Url::parse("https://google.com").unwrap();
app.create_window("command_window".to_string(), tauri::WindowUrl::External(external_url),
move |window_builder, webview_attributes| {
(window_builder, webview_attributes)
});
}
Results in:

Calling the same function from the setup function like so creates the window successfully:
fn main() {
tauri::Builder::default()
.setup(|app| {
let external_url = Url::parse("https://google.com").unwrap();
app.create_window("window_from_main".to_string(), tauri::WindowUrl::External(external_url), move |window_builder, webview_attributes| {
(window_builder, webview_attributes)
});
Ok(())
})
.invoke_handler(tauri::generate_handler![
spawn_window
])
.run(tauri::generate_context!())
.expect("error while running tauri application");
}
The exact same project works as expected on MacOS (version 12.2.1).
No console errors are present on the main window and the Dev Tools of the spawned window cannot be accessed (could be possible if there is another way than right click > inspect or F12).
Reproduction
- Clone the reproduction repo
cd tauri-window-issue
yarn install or npm install
yarn tauri dev or npm run tauri dev
The secondary window that pops up on load will successfully load the link.
The window spawned with the button: create window does not load the link on Windows.
OR
Create a window from a Tauri command invoked by JS.
Expected behavior
The window should successfully load the link when created from the AppHandle struct (?) on Windows.
Platform and versions
Windows:
Operating System - Windows, version 10.0.22000 X64
Webview2 - 98.0.1108.62
Visual Studio Build Tools:
- Visual Studio Build Tools 2019
Node.js environment
Node.js - 17.6.0
@tauri-apps/cli - 1.0.0-rc.5
@tauri-apps/api - 1.0.0-rc.1
Global packages
npm - 8.5.1
pnpm - Not installed
yarn - 1.22.17
Rust environment
rustup - 1.24.3
rustc - 1.58.1
cargo - 1.58.0
toolchain - stable-x86_64-pc-windows-msvc
App directory structure
/.git
/node_modules
/src
/src-tauri
App
tauri - 1.0.0-rc.3
tauri-build - 1.0.0-rc.3
tao - 0.6.3
wry - 0.13.3
build-type - bundle
CSP - unset
distDir - ../public
devPath - http://localhost:3000/
MacOS:
Operating System - Mac OS, version 12.2.1 X64
Node.js environment
Node.js - 16.3.0
@tauri-apps/cli - 1.0.0-rc.5
@tauri-apps/api - 1.0.0-rc.1
Global packages
npm - 7.17.0
pnpm - 6.14.5
yarn - 1.22.11
Rust environment
rustup - 1.24.3
rustc - 1.58.1
cargo - 1.58.0
toolchain - stable-aarch64-apple-darwin
App directory structure
/node_modules
/src-tauri
/.git
/src
App
tauri - 1.0.0-rc.3
tauri-build - 1.0.0-rc.3
tao - 0.6.3
wry - 0.13.3
build-type - bundle
CSP - unset
distDir - ../public
devPath - http://localhost:3000/
Stack trace
No response
Additional context
The behaviour has already been replicated on different environments (this was initially reported by a colleague).
Describe the bug
Creating a new window from the
AppHandlestruct with thecreate_windowfunction results in a blank window on Windows.Example:
Results in:

Calling the same function from the setup function like so creates the window successfully:
The exact same project works as expected on MacOS (version 12.2.1).
No console errors are present on the main window and the Dev Tools of the spawned window cannot be accessed (could be possible if there is another way than right click > inspect or F12).
Reproduction
cd tauri-window-issueyarn installornpm installyarn tauri devornpm run tauri devThe secondary window that pops up on load will successfully load the link.
The window spawned with the button:
create windowdoes not load the link on Windows.OR
Create a window from a Tauri command invoked by JS.
Expected behavior
The window should successfully load the link when created from the AppHandle struct (?) on Windows.
Platform and versions
Stack trace
No response
Additional context
The behaviour has already been replicated on different environments (this was initially reported by a colleague).