eframe on the web (egui_web) creates a mess on panic

[DusterTheFirst]

Describe the bug
When using eframe on the web (wasm), you call eframe::start_web to set eframe up. eframe::start_web installs many event callbacks into the DOM and a 1 second interval callback which are all used to render/update the application. This is fine and works perfectly when the application is in a valid state.

Because these callbacks call into rust code from the JS engine, when rust code panics from anything (in my example I use an explicit panic to show the behavior), the state of the rust code becomes undefined but the JS engine will continue to call into the wasm code, unaware that it has panicked. This leads to a spam of errors in the console which can be seen in the screencap below: Uncaught RuntimeError: unreachable executed.

This causes multiple problems:

1. Any panic message written to the browser's console like one from console_error_panic_hook would be hidden away by the error spam
2. The browser will continue to attempt to call the wasm code, leading to the continued RuntimeErrors which will slow down a browser's devtools and lead to a very unfriendly user experience.
3. The browser can call callbacks with the application in an invalid state, which can be seen in the screencap as the second panic caused by a RefCell's lock not being dropped by the panicking code.

To Reproduce
Steps to reproduce the behavior:

1. Setup an application using eframe running in wasm
2. panic anywhere in your code after initializing eframe

Expected behavior
The application would panic, printing the message to the console and would stop responding to user events.

to achieve this eframe could provide a way to de-register the callbacks registered in eframe::start_web that can be called in a panic handler, or eframe_web could provide/set a panic handler to do this without the need for a programmer to call the function themselves.

Screenshots

recordedVideo.mp4

Desktop (please complete the following information):

• OS: Windows 10 Enterprise (19044.1526)
• Browser: Firefox 97.0.1 (64-bit)
• egui/eframe Version 0.16.0

Additional context
The code for this can be found here and is built using trunk, but trunk should not affect the behavior of eframe.

[DusterTheFirst]

You can run this app in your browser using the following link and see the problem yourself by clicking the panic button on the left sidebar.
https://vocode.dusterthefirst.com/

[emilk]

This is not a solution, but it can be helpful to use https://github.com/rustwasm/console_error_panic_hook and https://crates.io/crates/tracing-wasm for better console logs.

I don't have the time to dive into this at the moment - would you like to take a stab at it?

I wonder if there is a standard solution to this problem. In what state is the WASM app (egui) left in after a panic? Is any callback into it always a problem?

[DusterTheFirst]

I will take a stab at it. I already have an idea of a solution, I will just have to familiarize myself with the code.

[KentaTheBugMaker]

add destroy function to egui_web and call it in panic handler maybe helpful in this case.