libui
libui copied to clipboard
andlabs
Master issue for web views
This is a commonly requested feature.
Will this feature inflate the size of libui too much? If so, I could make it a separate library.
What rendering engine should this use? On Windows, there's mshtml out of the box; on OS X, there's WebKit out of the box; on GTK+, there's WebKit as an extra installation. Would having different rendering engines result in strange inconsistencies? I could also use WebKit on Windows, but building the WebKit DLL and using its COM-based interface seems to be totally undocumented, if not difficult to even find out about in the first place.
And if we go with WebKit, do we go with API version 1 or 2 (OS X: WebView or WKWebView)?
My two cents...I think a separate lib is ideal (and is an ideal approach to all complex widgets that bloat the size of the primary lib). As an alternative, I suggest CEF. It works well across platforms and is basically de-googled. Qt took a similar approach though I think they compile Chromium themselves which I think is too burdensome for a lib like this to maintain. I will say unfortunately it is multi-process only.
My vote is to have native rendering engine also as they are super lightweight. We have native forms, buttons and scrolls and a native browser is just something should be there also just like other native UI component that UI development kits provide. Imagine electron like framework that doesn't have more than 1MB overhead... and of course WebKit based consistent layout engine is also something cool to have as a separate project.
I've already started working on this a bit. (#298)
I think zserge/webview is the way to go. Very minimalist, and can be turned into a libui control fairly easily. The whole implementation for all three platforms is one file, just ~2kloc! For comparison, libQt5WebKit.so on my machine is ~40mb. Yes, we absolutely want WebKit API version 2!
Also- some changes to zserge/webview:
- Upgrade to
WKWebView - Dynamically load
libwebkit2-gtk.sosymbols at runtime upon first call touiNewWebView, as it is an unacceptable compile-time dependency. - Make
webview_eval()asynchronous
I think we should use CEF, mostly for security reasons. WebKit is perhaps the least secure of all major browser engines, with Blink and Gecko as the two most secure. CEF works on all platforms, and (importantly) uses the same rendering engine as the most popular browser in the world.
Webview uses the platform-native web view, so security is going to be as good as the platform-native browser.
use platform native that add minimal size and dependency to the library would be fantastic. a shared webview will just make build and dependency more complicated.
Keep in mind a useful webview will result in API bloat no matter which approach is used.
True, but even a webview with just a single method to load static html would be very helpful.
So my current design for uiWebView is a straightforward port of zserge/webview, which has a very minimal API.
As far as dependencies go:
darwin backend: WebKit.framework is always present.
windows backend: ole32.dll and comctl32.dll are always present.
unix backend: Dynamically load libwebkit2-gtk.so symbols at runtime.
@cody271 did you start working on this? I need this feature and want to make it, but if you started already I don't want to reinvent the wheel ;)
@maciek134 Yes GTK+ backend will be ready first, curious what platform(s) are you interested in using with uiWebView?
@cody271 So one problem is that that library uses synchronous communication, which will stall the UI thread. We need to use asynchronous communication.
Additionally, WebKit is the least-secure of all major browsers (for example, it is the only one lacking a sandbox on Linux). I don’t think MSHTML has a sandbox either.
@DemiMarie,
uiWebViewEval() API is asynchronous, though we also have a uiWebViewEvalSync() for when that's useful.
Agreed, the security situation here isn't great. We're at the mercy of the underlying platforms.. Also keep in mind that the main use case is for embedded web content that's part of the application, and hence somewhat trusted. Nobody should be writing a general purpose browser with uiWebView.
FYI- The latest WebKit does ship with a sandbox on Linux:
$ dpkg -L libwebkit2gtk-4.0-37
/usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.28.3
/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess
/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitPluginProcess
/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitStorageProcess
/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess
...
Webkit is multiprocess on all platforms, but it doesn't include sandboxing support on Linux last I checked.
Given that uiWebView is not secure, would it be possible to restrict it to only being able to access localhost and file:// URLs? Also, would it be possible to hook certificate verification at all?
On Tue, Sep 4, 2018, 8:31 PM cody271 [email protected] wrote:
@DemiMarie https://github.com/DemiMarie, uiWebViewEval() API is asynchronous, though we also have a uiWebViewEvalSync() for when that's useful.
Agreed, the security situation here isn't great. We're at the mercy of the underlying platforms.. Also keep in mind that the main use case is for embedded web content that's part of the application, and hence somewhat trusted. Nobody should be writing a general purpose browser with uiWebView .
FYI- The latest WebKit does ship with a sandbox on Linux:
$ dpkg -L libwebkit2gtk-4.0-37 /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.28.3 /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitPluginProcess /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitStorageProcess /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess ...
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/andlabs/libui/issues/315#issuecomment-418560423, or mute the thread https://github.com/notifications/unsubscribe-auth/AGGWBxojKcRJ49-VPn906zoUf1yDpFVeks5uXxtdgaJpZM4S52dg .
Ah, you're correct.. WebKit sandbox looks to be completely broken and unlikely to be fixed. (See this post.)
Restricting web content to localhost & file:// by default is a great idea! Will definitely do that, thanks!
Not sure about certificate verification..
Perhaps it helps. The haskell port (beijaflor-io/haskell-libui) has an early implementation of a webview (at least for macOS).
Regarding sandboxing and untrusted code, I think it'd be better left to the application developer to add sandboxing to their app as a whole.
I'd want to be able to experiment with loading remote content and accept the risks. 😅
I strongly disagree. Running untrusted web content with no sandbox is an unacceptable security risk nowdays. The only exception is if scripting is disabled, though even then I would be iffy.
Furthermore, Debian does not provide security support for WebKit, and its versions are often out of date. Windows presumably does provide security support for its embedded HTML renderer, but I do not believe Windows uses a sandbox for it.
I strongly believe that the best way to handle untrusted web content on all platforms except Apple is to spawn an actual browser and/or use the Chromium Embedded Framework.
On Oct 1, 2018 4:35 PM, "RangerMauve" [email protected] wrote:
Regarding sandboxing and untrusted code, I think it'd be better left to the application developer to add sandboxing to their app as a whole.
I'd want to be able to experiment with loading remote content and accept the risks. 😅
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/andlabs/libui/issues/315#issuecomment-426053173, or mute the thread https://github.com/notifications/unsubscribe-auth/AGGWBwdWIwQU54Pw-GXt_0L7uE7h1mr7ks5ugnx3gaJpZM4S52dg .
@DemiMarie then only allow local content? Adding ~50MB to the lib just for the sandbox is unacceptable. Restrict to local content by default and if someone wants to disable that let them.
@cody271 sorry, I didn't have time last month. I wanted to use it mainly on Linux, but I wouldn't mind additional Windows support and am willing to implement it.
@DemiMarie, yeah that's a good point.
I can totally see why a default of loading only local content would be great, but I don't think that disallowing remote content is the best way forward. People will find work arounds if they need to and it'll mostly just make it more annoying.
A thing to consider is that the remote content won't always be untrusted, and even if it's local content it won't necessarily be trusted.
I get that it should be more difficult to shoot yourself in the foot, but I don't think that it should be outright forbidden.
Local only is definitely the sensible default here. Current design has:
If your application needs remote, simply will need to set uiWebViewOptions.RemoteContent = 1;
As discussed before, I'm still not sure how CEF makes any sense for libui.. for reference:
$ du -h libcef.so
131M libcef.so
Maybe CEF in the future as a separate additional library (if chrome is really needed).
Actually since Microsoft Edge go to chromium, Chromium actually is inevitable. We need an ALL in one library, that can using most native UI, and go to webview whenever there is the need to display web content/web UI.
Recently working on UWP, easily sample app using 50mb memory, I still remember getting started Electron also using 50mb memory. I am guessing Cario / UltraLig.ht or CEF is the best bet as long as we keep pushing optimization of Chromium.
Despite being a Google employee, as a devoted Firefox user I would like to live in a world where Chromium is not inevitable. (And even then, the "inevitable" Chromium would still not come with Windows by default before some future major version of Windows 10, which will be a problem for libui.)
THAT BEING SAID, what we provide depends on what is necessary to provide, and I can only judge by what I already know I will need for github.com/andlabs/ohv. At the same time, I'm not sure how much I want to limit people from working, even for security purposes — why would WebKit not have the same limitations natively?
My use case was a widget that would display a React/Angular/Vue/etc component you are working on in isolation with ability to tweak the props. I'd really not worry about sandboxing - it's the developer's responsibility as the one who is actually embedding the content to take care of that.
UWP (which is basically dead at this point) taking 50Mb of memory is not an argument for CEF, but an argument against UWP.
Wait, since when was UWP dead? Did Microsoft backport all the UWP-only stuff like acrylic frames to Win32?
Yup, https://www.zdnet.com/article/microsoft-wants-to-close-the-uwp-win32-divide-with-windows-apps/ Of course they are not actually deprecating UWP, but there is no reason to use it anymore. They even open-sourced the WinUI components: https://github.com/microsoft/microsoft-ui-xaml
Ah, good to know. And I see they did indeed open source the Acrylic effect, so it's probably possible to do with Win32 now, even on non-Windows 10 systems... except for the CreateBackdropBrush()/CreateHostBackdropBrush() methods, which is where the blending-with-content magic happens and which are not in the open-source components...
I would like to suggest using Ultralight as an ultralightweight cross-platform webview. Here is a sample browser:
Ultralight is not even source-available, let alone open source or even free software. Which is a shame, because it does seem interesting. (Also why would it be on github if it was proprietary?)