Support non-blocking render

[exoRift]

Introduced by https://github.com/webview/webview/pull/1308

I doubt this will be merged while the PR is open and pointing to Complexicon's fork, but I needed this so at least this PR being open can point people in the right direction

Edit:

I switched the webview submodule to my own instead of Complexicon's to add some MacOS functionality discussed here

(closes #35)

[CoreBytee]

Hi,

This looks awesome! I’d love to try it out, but I noticed there aren’t any Windows binaries. Can you add those to the repository, or do I need to build them myself?

Thanks!

[exoRift]

Hi,

This looks awesome! I’d love to try it out, but I noticed there aren’t any Windows binaries. Can you add those to the repository, or do I need to build them myself?

Thanks!

It seems the platform is determined by the platform being built on (i.e. no cross-compilation) and I don't have access to my other machines at the moment.

For the moment, it seems you'll have to build it yourself; my apologies

If you know how to cross-platform compile, I'd be happy to update it

[CoreBytee]

One possible solution is to use GitHub Actions. It looks like there's already a PR addressing this (#29). Maybe you could take a look at that?

[exoRift]

One possible solution is to use GitHub Actions. It looks like there's already a PR addressing this (#29). Maybe you could take a look at that?

I've implemented actions to build the binaries. I'm concerned, however, because the sizes for two of the files are smaller. Please test them to make sure everything is working correctly.

Please ignore all the force pushes. That was me amending the commit that adds the GitHub Action to get it to work

[CoreBytee]

It looks like the DLLs are working since a window is created, and the onClose callback is functioning as well. Is there anything else that needs to be tested?

[exoRift]

It looks like the DLLs are working since a window is created, and the onClose callback is functioning as well. Is there anything else that needs to be tested?

I guess not. Cool

[CoreBytee]

Hi, I found that when you use multiple windows, the close event is only fired after all windows are closed. Could you maybe look for a fix? Thanks in advance!

[exoRift]

At some point I switched it from using EventEmitter to just taking a callback on runNonBlocking. Try pulling the latest commit and see if that works

[CoreBytee]

I'm already on the latest commit 😅. I'm on Windows, if that changes the issue in any way...

[exoRift]

Could you send me some example code to try out so I have more clarity into the issue?

[CoreBytee]

This is my index.ts:

import { Webview } from "webview-bun"

const webview1 = new Webview()
const webview2 = new Webview()

webview1.runNonBlocking(() => console.log("webview1 closed"))
webview2.runNonBlocking(() => console.log("webview2 closed"))

And this is my package.json (with the latest git commit hash):

{
    "scripts": {
        "dev": "bun run --watch index.ts"
    },
    "dependencies": {
		"webview-bun": "exoRift/webview-bun#b805351391e58d0cce4c3b15d92cae192b6b1dda"
    }
}

Hope this helps!

[exoRift]

It was an upstream issue with Complexicon's implementation. I've fixed it in my fork.

Once the build action finishes (https://github.com/exoRift/webview-bun/actions/runs/16531577944), it will be available at the latest commit on main. Let me know if you run into any more issues!

[CoreBytee]

Now both windows close if the user closes one of them...

[exoRift]

Yep, you're right. I didn't observe this on Mac but I tested it on Windows and it happened. I'll take a look

[exoRift]

Should be fixed now! Tested it myself (I hope I didn't screw up 😅)

https://github.com/exoRift/webview-bun/actions/runs/16553419049

[CoreBytee]

It works🎉, Thank you very much!

[gabereiser]

Would be better if it were:

webview.runSync();
await webview.run();

to be more in line with the rest of bun...

Also remove the changes to webview prebuilt binaries and your own repo (fine for your setup, not fine for everyone else). Let's work on publishing changes upstream to webview. 😃

[exoRift]

Originally, the PR pointed to Complexicon's fork which added the ability to manually pump the event loop (allowing for this implementation) which is still a fork.

My fork adds some missing functionalities to Mac as well as corrects some issues present in Complexicon's fork/the original webview implementation for Windows.

Thus, my fork is needed for stability.

It couldn't be merged anyway because it's always pointing to a fork of webview regardless.

I also don't really have any intention of this actually getting merged into webview-bun but it's moreso open so people can easily find my fork to use for their own purposes. I've also implemented Github action workflows to auto-build the binaries which is technically its own scope and not suitable for this PR

In summary, it doesn't really matter since this isn't really open to be merged anyway

[CoreBytee]

If you don't plan on merging, could you maybe take a look at publishing this as a standalone NPM package?

[exoRift]

Is there any need for that? I think that may be a bit disrespectful to the original package creators, not to mention it would need to be maintained and kept up-to-date.

This package is specifically for Bun which natively supports repo dependencies so what ease of use would it introduce?