Webview via Extensions

[notpeter]

Check for existing issues

• [X] Completed

Describe the feature

A number of VSCode plugins are implemented as shim atop a webview.

This can be used to support simple things like Preview panes (e.g. image/PDF/SVG preview) up through through full interactive web applications which dynamically edit an underlying file.

Example requests which could potentially implement with this extension interface:

• https://github.com/zed-industries/zed/issues/12088
• https://github.com/zed-industries/zed/issues/21197

Environment

N/A

If applicable, add mockups / screenshots to help present your vision of the feature

No response

[huacnlee]

I have made this change for WebView support. And we are already used those changes to integration WebView in our application.

https://github.com/huacnlee/zed/pull/6

There still have a big problem:

• The WebView will always render on top of the GPUI elements.
  • So we are limited our UI, to let the WebView render in a Drawer or a Modal to make sure no other GPUI elements render on top of it (e.g.: PopupMenu, Tooltip ...).
• On Linux with Wayland, the Wry can't be as a child window to use.
  • So ... we disable it in our application on Linux.

[notpeter]

There will definitely need to be significant work as for how to expose this the API in a platform agnostic way (e.g. bundle Chromium everywhere? Use native Safari WebView on Mac, Edge WebView2 on Windows, ?? on Linux) as well as the specific ergonomics/safety of the Extension API so that extensions can leverage it and Zed can support this as a stable API in the long-term.

Thanks for the link @huacnlee, it's exciting to see a proof-of-concept. But I want to manage expectations -- there is still significant work to be done here and it's likely still a ways off.

[mocenigo]

Something like skia-canvas would be good to get a nt Html canvas. Since the backend is separated I think it could be ported atop of GPUI. With JS and TS also compiling to wasm, I think this could allow fast porting of several VSCode extensions (imagine having draw.io).

[indrajit-roy]

Given one of Zed's core advantages of being fast and having a low memory footprint I doubt how much of that can be maintained if it starts supporting web views. IMO even if it does make sense to do this to quickly import vscode extensions, having a tag on the extension, say non-native or vice versa having the native tag on pure rust extensions, would help the user understand the trade-off he/she is signing up for.

[JakkuSakura]

Do we have alternatives? On Wayland, we could render webview to a bitmap or hidden x11 window, then copy content over to the wayland window. This way, even though it's slower, but there are something to show. Or we could dive deeper and figure out why it's not working with wayland

[yannicka]

Perhaps in the future we could display webviews thanks to Servo (https://servo.org/)?

[TheBarzani]

Servo seems like a solid option here especially given that they share a similar mission with Zed in terms of high performance and memory footprint.

[mocenigo]

What's wrong with using the platform's native rendering libraries when they are available?

[ifsheldon]

Also see the latest Blitz 0.1!

[notpeter]

@ifsheldon I thought this was just spam. It was a link to fly.dev site, there was placeholder text, etc -- I just assumed this was a fake site and was a little quick with the ban hammer. My apologies. Thanks for reaching out so we could unban.

[ifsheldon]

@notpeter OK, I think to ban or block some one should be serious. It should only be applied to someone who really seriously violates CoC. Blocking/banning should be a dangerous action that is not a click away. Anyway, I don't want to yell at anyone now, nor spamming this issue by continuing this further.

But I do think Blitz is a candidate worth considering. I was too exciting about its initial release along with Dioxus-0.7-alpha to elaborate this in my last comment. I think as it is to be a super modular CSS/HTML renderer that powers Dioxus Native, it's probably more suitable for Zed than Servo, which is full-fledged. You can pick modules of Blitz that are relevant to previewing content so the performance/memory footprint should be smaller. I share some empathy with native webviews, though. But I think Servo or Blitz should be more manageable for multi-platform apps like Zed.

[Zollerboy1]

Another possible path towards extension-defined UIs could be to expose (a subset of) GPUI to the wasm runtime. I imagine a special context where extensions could render some GPUI elements or something like this.

[zaunere]

The web view is a tool of the big tech oligopoly. It's been so poorly written, defined and manipulated over decades, that for every great true community driven project, there's the web view "standard" in the way, which are gladly written by organizations fully funded by big tech, and maintained not by the community, but by a full-time team of employees.

We don't need to support 25 year old JS when those companies don't even honor the Accept-Language header.

And GPT certainly doesn't need to burn through an average of 90% Javascript vs 5% actual content for every web request.

The community subconsciously knows all of this and thus the move to markdown; when that's actually what HTML is for!

I see so many incredible true open source projects get "mooted" because they can't get past the web view.

There are more kernels than web engines. It's broken, misguided and corrupt technology that has put low-level hardware access - device GPS - into the HTML spec - what's low-level device access doing in a markup language!?! - that can't "center" correctly? And the DOM? Flash would've been better. RSS?

Sorry for the rant, probably better if this is moderated but I do hope the communities start thinking about this more.

[github-actions[bot]]

Hi there! 👋 We're working to clean up our issue tracker by closing older bugs that might not be relevant anymore. If you are able to reproduce this issue in the latest version of Zed, please let us know by commenting on this issue, and it will be kept open. If you can't reproduce it, feel free to close the issue yourself. Otherwise, it will close automatically in 14 days. Thanks for your help!

[teohhanhui]

Bad bot. Not stale.

[nahuel]

Another possible path towards extension-defined UIs could be to expose (a subset of) GPUI to the wasm runtime. I imagine a special context where extensions could render some GPUI elements or something like this.

Related: https://github.com/zed-industries/zed/discussions/37270