[bug] deno-webui crashes if you open a window after closing all windows #66
Comments
|
Thank you for sharing 👍 |
|
Clone c703d73 async function allEvents(e: WebUI.Event) {
/*
e.window: WebUI;
e.eventType: number;
e.element: string;
*/
console.log(`allEvents: window = ${e.window}`);
console.log(`allEvents: eventType = ${e.eventType}`);
console.log(`allEvents: element = ${e.element}`);
if (e.eventType == 0) {
console.log(`Window closed, open it again...`);
myWindow.show(myHtml);
}
}
WebUI.setTimeout(0);
WebUI.setMultiClient(true);
myWindow.bind("", allEvents);
// Show the window
myWindow.show(myHtml); // Or myWindow.show('./myFile.html');
// Wait until all windows get closed
await WebUI.wait();
console.log("Thank you."); |
|
Success! Jumping to that commit id and testing with your code appended to the hello_world.ts example I get new windows after closing the previous one and no errors! Thank you for the incredibly fast response. 👌 |
|
Oh, but you typed setMultiClient's parameter as |
|
You are right, would you please fix it in a PR? |
|
No problem, I've created a pull request. |
|
Huh... it appears that by using When I don't use multiclient, |
|
Good catch! |
|
Okay. To make this work, we need to add However, I created this issue, hopefully those interfaces will be implemented soon... they are easy to implement anyway... |
|
I understand, thank you for the explanation. Meanwhile I can live without |
|
scriptClient is available now (e3511bd). async function myCallback(e: WebUI.Event) {
e.window.scriptClient(e, `alert('test');`);
}
setMultiClient(true); |
|
Thank you, However, something appears to have gone wrong. The example you gave above showing |
|
I just re-test it, it's working fine! |
import { WebUI } from "https://deno.land/x/webui@2.5.1/mod.ts";
const myHtml = `<html><script src="webui.js"></script> Testing Re-Open window! </html>`;
const myWindow = new WebUI();
async function allEvents(e: WebUI.Event) {
/*
e.window: WebUI;
e.eventType: number;
e.element: string;
*/
console.log(`allEvents: window = ${e.window}`);
console.log(`allEvents: eventType = ${e.eventType}`);
console.log(`allEvents: element = ${e.element}`);
if (e.eventType == 0) {
console.log(`Window closed, open it again...`);
myWindow.show(myHtml);
}
}
WebUI.setTimeout(0);
WebUI.setMultiClient(true);
myWindow.bind("", allEvents);
// Show the window
myWindow.show(myHtml); // Or myWindow.show('./myFile.html');
// Wait until all windows get closed
await WebUI.wait();
console.log("Thank you."); |
|
Oh! I figured out the root cause of the issue. If I have a window of Google Chrome open when I try the example, then WebUI uses Google Chrome to open it's popup. If I close this popup, it re-opens as expected.
However, if I don't have Google Chrome open when I try the example, then WebUI uses Firefox (my default browser) to open it's popup. If I close this popup, it fails and gives the error.
So it appears WebUI has some problem when using Firefox as it's browser. Also which browser you have running currently seems to affect what choice WebUI goes for. |
|
You are right, I can reproduce the issue using Firefox. Yes, webui use the running web browser for efficiency |
|
Makes sense, thanks for the explanation. 🙂 |
|
After testing and looking at logs, it seems to me that webui is too fast for Firefox... To fix that, just add a few seconds delay before reopening and all will be fine. if (e.eventType == 0) {
console.log(`Window closed, will reopen in 1 second...`);
await new Promise(resolve => setTimeout(resolve, 1000)); // Sleep for 1 second
myWindow.show(myHtml);
} |
|
(Unrelated, but I changed my username, but it's still me, Drakim) Aha, good catch. I will do so. But this could potentially confuse future users of WebUI who don't know to insert the setTimeout(). Isn't there a way to sorta see if firefox is busy and build the delay into the library? Or abort the request and try again if it fails a couple of times? Either way, I know enough to work my way around the problem, thank you very much for investigating the issue. |
|
I see your point, but it's better to make library general and not specific, I mean some users prefer the event to be fired fast and as soon as possible without any delay, other users like in your app you prefer a delay, so to make both scenarios working, the library fire the event as fast as it happen, then it's up to the user to deal with the event depend on his project needs. I believe I saw a lot of official Microsoft C++ Win32 APIs example where Microsoft add delays in the example, while APIs stay fast as possible. |
|
Hm, makes sense. |
|
I've been testing a bunch, and here is what I've discovered:
I understand WebUI is still heavily under development, and that nobody can expect a perfectly stable product this early in development (WebUI website does say "In development...." for most things under Deno). But these issues will be blockers for anybody wishing to try the library even for a trivial case. I've been happy to help out finding out issues and problems so far, but I will either have to pause my own project until WebUI is more mature or switch to some other library. I can't even show off my project as a prototype to somebody if clicks takes several seconds to apply and the app randomly crashes. 🥲 Still, thank you for the work so far. WebUI will be amazing once it's fully available on all platforms. |
|
Yes, the Deno wrapper still under development. Thank you for reporting all those issues, I will fix them one by one soo.
In my opinion, browser mode is good for one single window project, while WebView is better for multi window projects. |
|
If at any point you close all windows spawned by deno-webui, you will be unable to spawn any new windows as deno will crash from an uncaught error:
To see this bug in action, simply modify the hello_world.ts example so that it works like this:
This happens to me on Windows 11.
The text was updated successfully, but these errors were encountered: