[feat] Catch tauri errors

[thewh1teagle]

[feat] Catch tauri errors

[Legend-Master]

Ah, got it

C:\Users\1234>[2024-06-30T23:19:39Z DEBUG vibe_desktop] Vibe App Running
[2024-06-30T23:19:39Z ERROR tauri_runtime_wry] failed to create webview: WebView2 error: WindowsError(Error { code: HRESULT(0x80004002), message: "No such interface supported" })
[2024-06-30T23:19:39Z DEBUG vibe_desktop::setup] webview version: 100.0.1185.36
[2024-06-30T23:19:39Z DEBUG vibe_desktop::setup] CPU Features:
    AVX: true
    AVX2: true
    AVX512: true
    AVX512-VBMI: true
    AVX512-VNNI: true
    FMA: true
    F16C: true
[2024-06-30T23:19:39Z DEBUG vibe_desktop::setup] COMMIT_HASH: cc1bb4f721a794c58081b139e57808c6ec8e00a5

https://github.com/thewh1teagle/vibe/blob/434e922ac386c3a45e989b094c8d25a85895eb5c/desktop/src-tauri/src/setup.rs#L73

Looking at this, it seems like the failed to create webview error happened before WebviewWindowBuilder::build, presumably before the whole setup function, and that probably explained why the panic hook didn't work

It seems like it's creating windows before setup hook which should be from config files but I don't see any windows from your config files, pretty strange

[Legend-Master]

Yes, with webview_version

[Legend-Master]

Seems like we use ICoreWebView2Environment10 which requires 101+ to support setting incognito mode, maybe we can skip that cast if we don't use incognito?

https://github.com/tauri-apps/wry/blob/f9e6bcc032369c6d5e7ce0284406953a16da3d82/src/webview2/mod.rs#L330-L331
https://learn.microsoft.com/en-us/microsoft-edge/webview2/reference/win32/icorewebview2environment10?view=webview2-1.0.2478.35
https://learn.microsoft.com/en-us/microsoft-edge/webview2/release-notes/archive?tabs=dotnetcsharp#10121039

Seems like this is also when theme API gets added, probably could document when it's added and skip it instead of returning error for unsupported platforms

Let me catch such errors

I might be wrong but looks like you're using expect here?

https://github.com/thewh1teagle/vibe/blob/434e922ac386c3a45e989b094c8d25a85895eb5c/desktop/src-tauri/src/setup.rs#L73

[thewh1teagle]

I might be wrong but looks like you're using expect here?

Let me catch such errors. currently I don't get anything from it. I even have a panic hook, but it doesn't kick in since seems like the event loop just keep runing.

[Legend-Master]

I don't quite get it to be honest, expect will panic the thread on error, if you want to handle the error you can just use the returned Result from it or do you mean it's crashing at somewhere else?

[thewh1teagle]

I don't quite get it to be honest, expect will panic the thread on error, if you want to handle the error you can just use the returned Result from it or do you mean it's crashing at somewhere else?

Sorry, I should have explained it better. Even though I'm using expect, it never gets there. Like I said, if the webview fails to start (like with an old version), tauri logs the error, but expect isn't hit, and the event loop just keeps running. Hope that makes more sense!

[thewh1teagle]

and that probably explained why the panic hook didn't work

In addition the process kept running (the process was still listed in task manager)

[bukowa]

Is it possible to also detect an outdated webview version and ask the user to update?

[Legend-Master]

Looking at the failed part

tauri/core/tauri-runtime-wry/src/lib.rs

Lines 3267 to 3295 in 88552d6

	Message::CreateWebview(window_id, handler) => {
	let window = windows
	.0
	.borrow()
	.get(&window_id)
	.and_then(|w| w.inner.clone());
	if let Some(window) = window {
	match handler(&window) {
	Ok(webview) => {
	windows.0.borrow_mut().get_mut(&window_id).map(|w| {
	w.webviews.push(webview);
	w.has_children.store(true, Ordering::Relaxed);
	w
	});
	}
	Err(e) => {
	log::error!("{}", e);
	}
	}
	}
	}
	Message::CreateWindow(window_id, handler) => match handler(event_loop) {
	Ok(webview) => {
	windows.0.borrow_mut().insert(window_id, webview);
	}
	Err(e) => {
	log::error!("{}", e);
	}
	},

Probably because we sent the window creation to the main thread and executed there, and you can't really handle that error, this is similar to other functions that needs to be executed on the main thread, you can't catch errors for those functions either

Not sure if it's worth it to send the error back

[thewh1teagle]

Not sure if it's worth it to send the error back

In case of error there the process will keep running normal without showing anything to the user and it's hard to debug it in production.

I also have panic hook that write to log but it won't was write either.
The only way I could understand the issue in production is telling the user to enable logs (tracing+tracing_subscriber), restart the cumputer and then copy for me

[Legend-Master]

I also have panic hook that write to log but it won't was write either.

Because it didn't panic as the code shown above

The only way I could understand the issue in production is telling the user to enable logs (tracing+tracing_subscriber), restart the cumputer and then copy for me

For my case, I'm using the log plugin and it did catch this in the log, but this is not ideal anyway to be honest

I did another PR to make wry run on webview2 version before 90, probably will mitigate this a bit more
Ideally it should never fail but in reality probably we still need some way of letting the devs to handle it

I'm not familiar with the original design of this, @lucasfernog @amrbashir, any ideas?