Implement a native WebView node

[YuriSizov]

Describe the project you are working on: A "News"/"Release Notes" section within game menus.

Describe the problem or limitation you are having in your project: It is not uncommon for games to rely on HTML-based content to display things like news, updates, release notes, help, EULA/TOS. Currently Godot provides no first-party option to integrate such content. This means that developers requiring such functionality either need to implement all of those using Godot systems, or provide a link that opens in another application and takes a user out of the game.

Describe the feature / enhancement and how it helps to overcome the problem or limitation: A WebView node can be introduced to allow display of both local and remote HTML documents. On many systems WebView is already a type of component that can be added as a part of UI, so this way it maps perfectly to how native apps are designed and fits Godot's node-based structure.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams: While it is not impossible to introduce something like that using a third-party module and Chromium, this provides a challenge for first-time developers and designers with limited coding experience. We could make a first-party module with the same Chromium or WebKit based solution. but obviously, Godot should not rely on such things for a secondary feature. This would be an unnecessary bloat.

However, many platforms provide a native WebView component, that can be integrated with some work by us or reliance on a third party library. Quick search yielded zserge/webview, though I'm not experienced enough to speak to its quality. Also, I don't see mobile platforms mentioned there.

But this library still demonstrates that it is possible to integrate native WebViews on all desktop platforms, while on mobile it is a given for both Android and iOS. So a WebView node would hide a native WebView component, that has platform-specific implementation. And for HTML5 exports it can be replaced with an iframe tag, for example.

The API such node should provide can be determined based on capabilities of various platforms, but it should at least support opening a web URI and a local HTML document (provided as a res:// path or as a text content).

It should introduce signals for DOMContentLoaded, HTTP errors, navigation events, if navigation is supported.

It should probably be a Control-based node with a bounding rectangle that defines the viewport for the HTML document.

I don't think that any data pass-through between a WebView and the parent application should be allowed. I believe this feature is beneficial for displaying content only. No JavaScript.eval and no callbacks.

If this enhancement will not be used often, can it be worked around with a few lines of script?: Definitely not a few lines of script.

Is there a reason why this should be core and not an add-on in the asset library?: It is possible to introduce this as a module, however given that we can make it a relatively small built-in module I'd opt for a solution available to everybody. Especially, given that HTML is much more accessible for first-time devs and general public, which can drastically reduce development time on some features for less experienced folks.

PS. This proposal is totally not inspired by a thought to have an HTML5 Godot Editor running within a native Godot Editor. I promise!

[Calinou]

I really think this should be a third-party module. All the full-featured WebViews I've seen (read: WebKit, CEF) are huge and a pain to build. zserge/webview uses the OS-provided WebView, whose quality varies wildly depending on the host OS*. (Do you really want to spend more time testing across platforms? We have enough platform-specific issues in Godot as it is.)

*: That said, for simple use cases like displaying release notes, differences across browsers are probably unnoticeable.

I also don't think we have the manpower to officially maintain a WebView integration. Also, keep in mind many people dislike WebViews vehemently and might avoid Godot altogether if a WebView is bundled by default :wink:

It is not uncommon for games to rely on HTML-based content to display things like news, updates, release notes, help, EULA/TOS.

Your CMS or static site generator could be configured to output machine-readable JSON files, which can then be nicely presented in a RichTextLabel. This is a relatively easy solution that doesn't involve adding anything to the engine. It's also the best-performing solution, and one that won't bloat binaries :slightly_smiling_face:

TL;DR: Think in problems, not solutions. WebViews are rarely conductive to a really good user experience. I use WebView-based software every day, but I also want Godot to keep its blazing fast UI layer.

[YuriSizov]

I think this should really be a third-party module. All the full-featured WebViews I've seen (read: WebKit, CEF) are huge and a pain to build. zserge/webview uses the OS-provided WebView, whose quality varies wildly depending on the host OS. (Do you really want to spend more time testing across platforms? We already have enough platform-specific issues in Godot as it is.)

My proposal is to rely on the OS-provided WebView and not to include things like CEF. The possibility to do so is the reason I've posted it at all. I don't want Godot to bloat with CEF or other HTML rendering library. I hoped I had explained it well enough in the opening post to eliminate such assumptions. I guess not.

Edit: I've edited the OP to hopefully clarify the idea I propose. Should've been more clear about my proposed solution.

Quality of those built-in WebViews can differ, that is true, but as evident from that zserge/webview library, all of the desktop platforms currently have a WebKit/Blink based WebView, and the same applies to the native components on mobile. So some level of consistency can be expected.

Your CMS or static site generator could be configured to output machine-readable JSON files, which can then be nicely presented in a RichTextLabel. This is a relatively easy solution that doesn't involve adding anything to the engine.

That may be an easy solution for a programmer, but not everyone who starts with Godot is one. Plus, some things can be pretty hard to convert to the RichTextLabel format, even if there is a tool to translate HTML to something intermediate. Overall, this is not a welcoming opportunity in some cases, as this constitutes double work for the benefit of supporting Godot-specific implementation for things that can be used in multiple places at once.

Think in problems, not solutions.

This is a problem. Why spend time converting your lengthy EULA or documentation to some limited and engine-specific BBCode format, when you could just display an HTML, that is already on your website or that you are much more comfortable to deal with even if creating it anew?

I also want Godot to keep its blazing fast UI layer.

I don't see how this is related to Godot's overall UI experience. This is just one control to display some textual information with tables and images. I do not propose adding it as a way to circumvent the UI system. Strictly to display docs.

---

I've even tried to make my proposal as limited and as focused as possible, so that we can separate the particular need from a general use "built-in browser" some may unwarrantedly want. I don't propose that. I propose a way to work with what each operating system already provides and costs us not that much given the accessibility of a thin-layered implementation to solve a particular situation.

Engine should lower the cost of development, not invent artificial limitation where none are required. I point it out again: I propose using what is already there on everyone's device, can reliably render straight-forward HTML and doesn't require a lot to support.

[Calinou]

My proposal is to rely on the OS-provided WebView and not to include things like CEF.

This sounds much better to me. Still, I'm not very confident that zserge/webview can be easily (cross-)compiled on all desktop platforms from SCons.

Also, is gtk2-webkit readily available on all desktop Linux distributions? If not, Linux users will have to install a package to run projects that use a webview (or even run Godot altogether, if we can't use dlopen() magic to handle it).

Why spend time converting your lengthy EULA or documentation to some limited and engine-specific BBCode format, when you could just display an HTML

An EULA rarely requires more elaborate formatting than a few bold and italic tags (and links). It doesn't even need any formatting to be legally valid.

[YuriSizov]

An EULA rarely requires more elaborate formatting than a few bold and italic tags (and links). It doesn't even need any formatting to be legally valid.

Well, I hope it doesn't invalidate the rest of my argument. 🙂

In any case, this is ought to be proposed at some point by someone. We had a go at it on Discord and figured that it would be beneficial to share the idea and research we had. Even if the consensus will be a firm "No" from the maintainers.

[YuriSizov]

Is gtk2-webkit readily available on all desktop Linux distributions?

Yes, Linux is probably the main concern with how non-standardizes it is. I cannot provide a good solution here, but I welcome any suggestions. If this is needed, wanted and greenlit, I'm sure we can find a solution that is going to be the most comfortable for both Linux developers and gamers. All I can say, license-wise both zserge/webview and gtk2-webkit seem to be fine for Godot to rely on.

[Zireael07]

zserge's webview is a wonderful thing, but recently I've been seeing a spate of issues on his repo amounting to people not able to compile/run (mostly on Windows)

[bruvzg]

zserge's webview is a wonderful thing

zserge's webview seems to only work in the separate windows, and lack even some basic features like setting its window position. And I do not see any way to use it for off-screen rendering. At least I have not found any after a half hour of trying it with GDNative.

Good enough to display EULA, but not so much for anything more complex, at least ability to insert it as the sub window overlay probably will be much more desired.

On the other hand, with the full size layout engine like CEF you can make GDNative module to do something like this (screenshot of the working, but extremely buggy prototype).

Obviously it's not reasonable to integrate CEF into the core, but if it's possible (should be, almost all native WebView are WebKit based, even Windows is moving towards it) it would be really nice and much more useful feature than simple popup window with HTML (for simple license popup, you can always run local built-it web server and open it in the default browser).

[Calinou]

(for simple license popup, you can always run local built-it web server and open it in the default browser).

You don't need to start a local web server for this if the HTML page is fully self-contained (or only references local CSS files).

[girng]

A news / release section, or a EULA page can easily be created using Godot's UI system. Simply fetch the JSON from your site, and dynamically create the UI nodes.

Having WebView IMO for this, is overkill. However, if it's an addon, I will not be against it

[YuriSizov]

A news / release section, or a EULA page can easily be created using Godot's UI system. Simply fetch the JSON from your site, and dynamically create the UI nodes.

This has been covered in the discussion above, so I'll summarize. Yes, everything can be recreated using Godot's UI system. However, I argue here that for some cases and some people it would artificially increase the time invested into the development, when each operating system already provides a simple way to integrate web-based content into any application. If our only option was to integrate a huge framework I would not had created this proposal.

Starting your point with "simply" does not necessarily make it so. You suggest that even though there is a cheap way to do something that can be supported across multiple platforms people should instead opt for a more complex solution just to make things work within Godot. And you imply that an option to "fetch the JSON" is readily available for everyone and any platform they run on.

However, if it's an addon

While it can be a module, it would be pointless for most of users who might benefit from it. Because it would require them to build the engine with that module themselves, instead of using a readily available solution. This complicates the development process even further for folks who may not be a programmer by trade. The point of making a thin proxy Node for the OS-provided WebView is to lower the cost of development and make this feature more accessible to less skilled or less invested people.

[raymoo]

Why couldn't it be a (GDNative) plugin?

[YuriSizov]

Why couldn't it be a (GDNative) plugin?

Sorry for not replying sooner, but I needed to educate myself a bit. Well, given that bruvzg already has a proof-of-concept done, the answer is "It totally can be a GDNative plugin". And maybe it is the way to do it, if such feature is undesirable and unneeded by the core team. But I'd still prefer to have it out of the box for better UX and discoverability.

[petergloor]

I'm currently exploring Godot as a GUI for an application I'm working on. A kind of HTML display control for a splash page and documents like the TOS is on my list of requirements. But I'm even going one step further and would like to integrate html/media content on objects in the scene as part of the game. As an example, imagine a 3D scene with a class room that contains a screen where on demand from the player a movie can be displayed.

[YuriSizov]

@petergloor You don't really need WebView to display media content, it can be displayed directly, unless your requirement is to specifically load, say, a YouTube page as it is and show it inside of your 3D scene. But such use-case is outside of the scope of this proposal, because complex webpages are a whole lot of problems to put on a game engine.

Well, I mean, existing WebView components can probably handle all of that too, but I wouldn't make that the focus of this proposal.

[petergloor]

@pycbouh After digging deeper into the details I agree, you are absolutely right, it would be an overkill. I've come to the conclusion to learn more about GDNative and experiment with existing WebView components for my specific project.

[Waridley]

I think this could also be useful for things like authentication and payments via third-party systems without leaving a fullscreen game window.

[bruvzg]

Some experiments with native web view embedding - https://github.com/bruvzg/webview_module

Overlay view works fine. Rendering to the texture is not fast and do not include media playback (e.g. YouTube videos) for some reason.

On Linux there is no standard native web view. ~webkit2gtk, which is the closest thing, probably won't embed itself into non-GTK window.~ ~(There's gdk_x11_window_foreign_new_for_display function which might work).~ Probably will require XEmbed protocol implementation.

Update: Now it works on macOS (WKWebView) and Windows (Edge WebView2).

res:// and user:// schemas works only on macOS, both supports loading from string, taking snapshots to texture, JavaScript execution and postMessage callbacks.

[wwderw]

What about embedding Servo for rendering versus webkit, especially with regard to the Linux platform? Interested, because I would really like something like this within Godot, although, having a simple server may be required for what I would use it for as well.

But following as this would be very beneficial for my use case as well.

[Calinou]

What about embedding Servo for rendering versus webkit, especially with regard to the Linux platform?

Integrating a Rust dependency in Godot's buildsystem won't happen due to the added complexity and (currently) poor console support: https://github.com/godotengine/godot-proposals/issues/1330

It's fine to do this as a third-party module, but it can't be a core feature. Also, I believe Servo is still pretty large when it comes to binary sizes, which further emphasizes the need to provide this feature as an add-on rather than a core feature.

[wwderw]

That's true, binary size on Linux is almost 350mb if I recall correctly.

I was thinking of it as more standardized view as it is cross platform as well, but that makes sense as to why it wouldn't work with Godot specifically.

[gururise]

Would love to see a fully-functional Webview (that works across Windows/Linux) as a plugin. Servo, Webkit or CEF.

[Calinou]

@gururise If it's made as a community plugin, we don't need a proposal for it in godot-proposals then :slightly_smiling_face:

I don't think feature is likely to ever be maintained as an official plugin. We only have so much manpower, which means we need to be selective in the kinds of plugins we can officially maintain.

[Xrayez]

I don't think feature is likely to ever be maintained as an official plugin. We only have so much manpower, which means we need to be selective in the kinds of plugins we can officially maintain.

Yeah, official or not, we still need passionate maintainers, and that's the gist of it. So far, I don't see anyone who'd be willing to work on this beside bruvzg who made a proof-of-concept for this proposal: bruvzg/webview_module#1.

Speaking as a user/player, I've never stumbled upon a game which uses a web view to display web content that way, so I consider this to be a quite specific use case to be implement both in core or as a first-party module.

As cool as it looks and sounds, there's a long way to go if we do end up implementing something like this in the future. The screenshots provided by https://github.com/godotengine/godot-proposals/issues/960#issuecomment-776099640 suggest to me that perhaps this may get popular and useful for VR/AR stuff, but even those use cases don't seem to be related to games.

Calinou is right to say that Godot's development should be based on solving problems that most people stumble upon, and not just seeking solutions in search of problems, especially when there are existing ways to solve the same problem. Future-proofing is also discouraged for Godot development.

Quoting Calinou:

I really think this should be a third-party module.

It's not crucial for a plugin to be popular for it to be a part of the organization. In fact, if we cultivate that environment where people completely ignore third party stuff, it would be a catastrophe.

[YuriSizov]

Speaking as a user/player, I've never stumbled upon a game which uses a web view to display web content that way

All Source games support this, many dedicated servers have HTML-based rich content for the MOTD screen. The only difference back then was that there were no good cross-platform solutions to render HTML like that. So I'm not entirely sure what they've used for it. Or, well, are using still.

While I've created this particular proposal, at the moment I have no immediate need in this solution. This did gather some positive reactions from others, though. Still, in the year since I've posted this I've grown to accept that this is likely better suited to be a third-party module. bruvzg's PoC is a very good starting point for it too.

[Xrayez]

While I've created this particular proposal, at the moment I have no immediate need in this solution. This did gather some positive reactions from others, though. Still, in the year since I've posted this I've grown to accept that this is likely better suited to be a third-party module. bruvzg's PoC is a very good starting point for it too.

@pycbouh is it safe to close the proposal, then? People will be still able to discuss this proposal regardless. I mean, GIP was created specifically to discuss proposals that are targeted for core development.

People reacting positively to this proposal may only approve the proposal as "cool/nice to have", it's not an indicator of something which is needed by the community in their real-life projects.

[YuriSizov]

is it safe to close the proposal, then?

Close it, if you so desire.

[Xrayez]

Close it, if you so desire.

I've only asked in case you've forgot to close the proposal yourself. Sure, I don't mind if this proposal is kept opened. 🙂

[dogman035]

Speaking as a user/player, I've never stumbled upon a game which uses a web view to display web content that way

All Source games support this, many dedicated servers have HTML-based rich content for the MOTD screen. The only difference back then was that there were no good cross-platform solutions to render HTML like that. So I'm not entirely sure what they've used for it. Or, well, are using still.

While I've created this particular proposal, at the moment I have no immediate need in this solution. This did gather some positive reactions from others, though. Still, in the year since I've posted this I've grown to accept that this is likely better suited to be a third-party module. bruvzg's PoC is a very good starting point for it too.

I'm a massive Source nerd and I'm basically in favor of any features that feel like Source.

I really want to say I'd want support for this, especially support as fleshed out as Source. Because you can do a lot of fun things with it there. The first thing that comes to mind for me is something like those old Gmod addons, a TV that can play YouTube videos or a radio that can stream music.

But... it's worth pointing out that Source was really only intended for PC, primarily windows, with some minor console support, and absolutely zero mobile support since that wasn't really a thing back then.

I think that's the main reason it worked out in Source, and that's the exact same reason I don't think it's really feasible here. It'd be a lot of work, both creating and maintaining, for a feature that only works in very specific games on very specific platforms.

I think it'd be better off as a plugin intended for use on the same platforms as Source.

[YuriSizov]

@dogman035 Well, the concept described in this proposal would work on all platforms supported by Godot officially, including mobile. As for console ports, those are out of the scope of the core project. I'm not sure if they provide any WebView like component, they might. But that's a problem to solve for those who work on console ports, not the core team.

[fire]

I might miss the proposal review, but I have support for this.

Technical proposal: We use operating system based web views, like edge on Windows 11, gtk on Linux and safari on the mac / ios similar to https://github.com/elixir-desktop/desktop which uses wxwebview https://docs.wxwidgets.org/3.0/classwx_web_view.html.

It is required to use an operating system webview. The security of the webview is the exact schedule as the os, so we would be exactly out of date as the os. Do not embed servo or chromium embedded.

Here are the use cases.

1. app authentication forwarding
2. showing messages from the developers
3. Playback of 4k/8k videos from a website.

Uses cases not recommended.

1. Do not use this for html5 ui for games.

[Calinou]

We decided in last week's proposal meeting that a WebView is a good candidate for GDExtension. It could be a community add-on at first, then it may be turned into an official add-on if there is significant demand and usage in real world projects.

Therefore, I'll close this for now, but feel free to rework https://github.com/bruvzg/webview_module into using GDExtension (and raise issues/proposals if there are blockers for this).

[Lecrapouille]

If people are interested we have succeeded to run CEF on Godot, see here for more information https://github.com/stigmee/gdnative-cef and I'm looking how to block the adds (CEF extensions with youblock like extension (if possible)).

PS: if people know how to optimize our CEF callback GDBrowserView::onPaint (src/gdbrowser.cpp at line 130) to fix my naive CEF texture conversion/transfer to Godot conversion, please ping me (here or in our GitHub discussion panel or as ticket, or in our Discord, whatever): 1/ There are many buffer copies (raw C pointer => PoolByteArray => BGRA8 -> RGBA8 conversion => Image => buffer) 2/ I did not find Godot API for using CefRenderHandler::RectList that would avoid transferring the whole texture but just a region.

Edit 1: since the license is GPL and the main project stalled, we have forked here under MIT license: https://github.com/Lecrapouille/gdcef and beware this is working for Linux and Windows. You need some work to make it work for Mac and CEF will not work for IOS and Android.

Edit 2: Module that can now be found on the Godot store: https://godotengine.org/asset-library/asset/1426

[realgdman]

Recently I discovered this project https://github.com/socketsupply/socket WebView wrapper Apache license C++, JS, Kotlin Compact builds, around 5-10Mb debug hello world

They claim to already support 5 platforms. Windows 11, 10 with installation of some microsoft runtime Linux, successfully tried on Ubuntu 22 Mac iOS Android 10-11. I have tried on Android 8.1, business logic failed, but app and chromium has launched. Even if not embedding project as whole, it can give some insights in platform specifics and architecture.

Regarding embedding into texture for 3d, not sure how webview will work, I've read that on Android it can be captured to texture, but it steals all input.

Other projects working on similar goal: https://github.com/wailsapp/wails - Golang, MIT license, has desktop, PoC on Android, planned iOS https://github.com/tauri-apps/tauri - Rust, MIT+Apache, has desktop, planned mobile Servo - alternative browser in Rust, android planned but not started yet. CEF, I guess, will never be on android and ios.

[Lecrapouille]

@realgdman CEF, I guess, will never be on android and ios true !

My main drawback concerning CEF: heavy artifacts to track (libCEF is +1 GB), if you cannot modify your application (like Godot) you have to compile and launch a second application (you have to know the exact path), at the beginning of the process: forks, forks, forks ... (bomb fork killing your OS if you made a mistake). Poor and unfriendly documentation. Linux, Win, Mac => 3 different code to start CEF. Single developer with +4K of issues to solve. Licensing issue for your project depending on you have compiled it. Prebuild CEF are mandatory if you do not have +60 GB of hard disk and +4 hours of compilation time. Chrome extensions limited to version 2, I'm not sure on how to develop an addblocker with CEF.

[Calinou]

@Overvault-64 Please don't bump issues without contributing significant new information. Use the :+1: reaction button on the first post instead.

[Pixel-Clay]

Is there any progress on this proposal? My application desperately needs a webview, and I am currently looking for the right engine to base it on. Am trying to avoid Unity as much as possible lol

[Calinou]

Is there any progress on this proposal? My application desperately needs a webview, and I am currently looking for the right engine to base it on. Am trying to avoid Unity as much as possible lol

This won't be implemented in core as per the above comments, but anyone in the community is free to tackle this as an extension. There have been some attempts linked above but to my knowledge, there is no WebView extension that is production-ready yet.

[Lecrapouille]

@Pixel-Clay my extension https://github.com/Lecrapouille/gdcef does not offer you what you want ? :( As @Calinou said, and I agree with him, this is not recommended to include ie CEF inside Godot. I initially tried to modify the main of Godot as explained here https://github.com/stigmee/doc-internal/blob/master/doc/tuto_modif_godot_fr.md#modification-du-main-de-godot-v34-stable (sorry in French) it worked for Linux but CEF and Godot both use the command line (CEF for forking), therefore a second application is needed (like done with my extension) but this make things harder, especially not working for IOS/Android, therefore not "production ready" .

[tamtakoe]

@bruvzg Do you have the issue https://github.com/godotengine/godot/issues/86533 for MacOS?

[ultimateshadsform]

I just wanted to add that even games like Battlefield 1 use react for it's "in-game" UI. More like react-native but still.

References: TIL Battlefield 1 user interface is powered by React+MobX