Bundle chromium renderer #1064
Comments
|
This is the crate that must be pushed forward to make it possible I guess Or hoping for a very far in time linux support for WebView2 |
|
I am circling back on this because it causes us so much pain on Linux that we are always discussing dropping Tauri because of it. I cannot overstate how bad webkitgtk performances are compared to browsers. |
|
We're aware of the situation and completely stopped defending webkitgtk ourselves. Sadly it is still a huge amount of work that we currently don't seem to be able to stem... Nonetheless, we do not see a future with webkitgtk. And i agree that using Tauri, or any similar framework using webkitgtk, is not a good idea for projects where Linux is a serious target, to a degree where i actively warn people about this (before the never ending webkitgtk-nvidia fiasco began i restricted this warning to performance intensive frontends but sadly we're past that now). My idea was to work on the webkitgtk 6.0 port (basically webkitgtk with gtk4) for tauri v3 and then some point after that look into cef again (my qt webview experiments never seem to work out 😩) if servo needs more time, but i've since changed my mind and will try my best to start working on an alternative for webkitgtk after v2 is stable. Hopefully to a degree where we can completely drop it but that may be a bit too optimistic. I also hope that @simonhyll is still interested in working on this too then ❤️ In the meantime, we can only apologize for any inconveniences (or worse) this caused any of you. |
|
Thanks for the answer @FabianLars, you guys are fighting the good fight. Honestly if Microsoft had any vision of would be awesome to have a webview2 standard across OS and it could be even a user setting (like use Firefox to provide webviews in my apps). Sadly we are not there yet. Seems like the latest webkitgtk shipped with gtk 4 support so there might be some improvements going there. But before that ships in the OS it is going to be years. That is kind of my main grip with native webview design, you often encounter really really outdated webviews even on recent machines and most of the time the user can't update it easily. CEF work I think is the way to go. Even better if the user can patch the chromium version without us. I know that for security oriented OS (like Parrot OS) the maintenance of electron apps is annoying because they cant easily patch the browser in case there is a critical CVE. |
Yeah, we hoped that they'd move faster on that part but even the macos port is still not public yet, though at least MS Teams iirc is using it now internally at least. Afaik planning for Linux still haven't begun.
Yeah, we were told that it's better, but the difference seems to be tiny. 🤏 Also it's not a trivial upgrade path on its own already, and additionally requires a complete rewrite of our tray implementation (because libappindicator requires gtk3) among other things.
True, but with our switch to webkitgtk 4.1 we've raised the minimum distro version already to the same versions that ship the gtk4 version too.
Yeah, ideally we could create a webview library out of it because each cef update by itself is technically a breaking change and could always break apps (to our current knowledge, though i hope i'm wrong and we can just share the lib files themselves between apps 🙏 ). Due to the urgentness of the situation imo we should get something working first even if the distribution method is not optimal. Appimages, our current main distribution format, require to bundle all cef libraries in it by design anyway. |
|
Fabian (not pinging cuz I'm quite a bit out of context with wry for a whole lotta time) |
|
There is a open feature request on Firefoxes feature request tracker: https://connect.mozilla.org/t5/ideas/create-an-alternative-to-electron/idi-p/268 |
We can't do it for / before v2. It's simply too much work and we don't want to hold back v2 any longer. |
While a Firefox alternative would be insanely nice, I highly doubt that we'll ever see anything close to it. Firefox' codebase is basically incompatible with this idea (and it's not like they're already overworked with just Firefox as a use case alone) |
Just wanna underscore that CEF definitely won't be in v2, hopefully it'll be in Tauri v3 or v4, depending on how fast Microsoft decides to come through on their promise of shipping WebView2 for Mac and Linux. Firefox definitely not happening since it's a browser not a webview, and Servo is years away from being an improvement over webkitgtk. |
I meant to just get the official cef that electron uses, at least on linux rn (ik there's a lot into it with the fact that most of cef releases is breaking) |
Electron doesn't use CEF, it's literally a custom build of the full Chromium browser. And there is no "just" with it, it's a huge undertaking, it can't be done for v2 both from an amount of work point of view and a security audit point of view. Earliest it can possibly happen is in Tauri version 3 |
|
@simonhyll Seems like I'm quite a bit out of context 😅 about the current state of cef, electron and tauri |
|
|
Would be there a way to use CEF on linux without embedding it? (By taking advantage of already installed browser on the system like chrome/chromium, ms edge, etc.) |
|
CEF? No, cef is a seperate thing and not part of any browser. |
Yeah, cef has to be made as a library like webkitgtk for it to work system wide |
|
The deal breaker is that every release of cef can be breaking |
|
Hi all, has any consideration been given to using Deno's |
|
not really because we need more than just v8. v8 is not a renderer or something like a webview, it's just the js runtime, so one (arguably large) piece of the puzzle. |
On July 6 they announced the following:
|
|
Yep, we're aware (and tbh we weren't that hopeful a while before that announcement anymore either). I thought we linked that announcement here but I guess I messed up so thanks for doing that! With this we're officially back to primarily CEF. I don't have anything to share except that we started talking about it a few days ago again x) I hope we'll have at least some kind of starting point or approach to share after holidays but we'll see... We're also keeping a close eye on chromiumembedded/cef#3836 if someone's interested in that. P.S. Servo of course is not forgotten but it is obviously not a proper replacement for many use cases still |
|
Completely different approach (maybe stupid approach), I worked some time ago with Puppeteer. And there was an option to find a local installation of chrome and run puppeteer from the already installed instance. Can this not be an option? to hook in on a already existing browser. |
|
browser_cookie3 has a bunch of paths for ChromiumBased browsers:
```
class ChromiumBased:
class Chrome(ChromiumBased):
class Arc(ChromiumBased):
class Chromium(ChromiumBased):
class Opera(ChromiumBased):
class OperaGX(ChromiumBased):
class Brave(ChromiumBased):
class Edge(ChromiumBased):
class Vivaldi(ChromiumBased):
```
https://github.com/borisbabic/browser_cookie3/blob/03895797e48dd107806db171d8392c562151807d/browser_cookie3/__init__.py#L431
…On Fri, Dec 20, 2024, 11:51 AM WesWeCan ***@***.***> wrote:
Completely different approach (maybe stupid aprroach), I worked some time
ago with Puppeteer. And there was an option to find a local installation of
chrome and run puppeteer from the already installed instance.
Can this not be an option? to hook in on a already existing browser.
—
Reply to this email directly, view it on GitHub
<#1064 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAMNS34BPW6GSL6EGBNNHT2GRDJLAVCNFSM6AAAAAA7DIBADOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJXGM3TKMZZGY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
According to Fabian, no: #1064 (comment) See also the Gluon project, which attempted that, but the creator determined that it would probably never work reliably |
|
Huge fun or Tauri here, we use it for almost all of our internal tools at Akina (where I work). When it came to decide on the technology to bundle our web app into a Desktop app, however, we had to go with Electron because we cannot afford testing and providing support for the different OSs. We're a small team with limited resources. |
|
Honestly if you need to bundle chromium with Tauri for it to be really cross platform compatible why not use Electron at this point? |
I mean, for literally all the other benefits Tauri offers over Electron. |
|
The goal is to make CEF an opt-in alternative to WebKit, likely targeting Linux since other platforms have superior webviews compared to WebKit. Additionally, work is underway to make CEF a shared dependency: chromiumembedded/cef#3836, so binary size still could be small... |
The main problem is that, every release of cef is breaking. And yeah, its kinda hard to integrate well |
|
that's what the linked issue is trying to solve |
Is your feature request related to a problem? Please describe.
The performances of WebkitGTK are really bad and the implementation often breaks. It is also hard to test for app maintainers since nobody really uses it outside of some obscure default browser. It is also not on the MDN compatibility list for API.
For all those reasons, there should be an alternative
Describe the solution you'd like
For better or worst, shipping a chromium renderer like electron does is the way all big companies ship their app today and the reason is simple: it works great. The experience is consistent for the user and it's not a pain to QA.
I think wry should support bundling a renderer.
Describe alternatives you've considered
I know that there is talk to integrate servo into it, but honestly it doesn't solve the compatibility and QA issue outlined above.
It's not a bad idea per say, so if it can be done in a modular way (feature flag
servoandchromiumwith some traits on top) I think that would be great.Would you want to assign yourself to implement this feature?
I am happy to contribute changes since I kinda know the codebase a bit by now, but it's a big change. I don't expect this issue to move the team on a dime, but I wanted to start the discussion.
The text was updated successfully, but these errors were encountered: