Improve IPC

[wusyong]

At the moment we exploit the following types to communicate between Panel webview and Verso embedder itself:

• webview can send message to embedder via EmbedderMsg::Prompt
• embedder can send message to webview via EmbedderEvent::Keyboard and Key::Character can contain a string. webview can listen to "keyup"/"keydown" and check if the string is a message.

While they can do their jobs, it doesn't seem like an ideal and ergonomic approach. We should evaluate better ways to do it. One method is adding register_uri_scheme, which is a fairly common feature for many webview libraries. But this only solves the problem of webview sending messages to embedder. We still need a way for embedder to send messages to webview proactively.

Despite how funny EmbedderEvent::Keyboard exploit is, I do like that webview can add an event listener to receive messages from embedder. Perhaps servo can public script crate's dom module for embedder to implement their custom Web API to achieve this?

[webbeef]

Hi! I just found that project, great to see a Servo based browser being worked on :)

I'm not sure I understand correctly the design used here, so bear with me if this is nonsense:

• the "panel" webview acts as some chrome/system UI to manage "browser" webviews.
• the layout of the panel & browsers is done with a native GUI toolkit.
• the prompt() DOM API and keyboard events are used as a hacky communication channel between the native side and the panel webview. This is what you're looking to improve here.

I have a couple of questions:

• how do you envision displaying chrome/system UI that can overlap with browsers, like history suggestions, permission prompts etc. ?
• what will be in charge of displaying the UI elements for the prompt(), alert() API when called from a browser? Ideally they would match the look and feel of the chrome/system UI of the panel.

Firefox UI is build with markup languages (XUL, and mostly HTML now) that use a special element (<xul:browser>) to embed web content. This element exposes event handlers and a rich api which is very similar to a webview api, but accessible directly from privileged JS code. FirefoxOS pushed the idea up to using only HTML (no XUL), but the principle remains the same. This makes it possible to fully build the UI in HTML without hacks to deal with overlaps etc.

In Servo that would require implementing a new element (maybe a custom element <web-view>) that can load top level content. I have no idea if that is feasible with the current embedding architecture but that would certainly be an elegant way to build the chrome/system UI. The JS code running in the chrome/system document would also need dedicated APIs to bridge with native code for some features - I feel this is what you're talking about in your last question?

cheers!

[wusyong]

* the "panel" webview acts as some chrome/system UI to manage "browser" webviews.

* the layout of the panel & browsers is done with a native GUI toolkit.

* the `prompt()` DOM API and keyboard events are used as a hacky communication channel between the native side and the panel webview. This is what you're looking to improve here.

Yes, this is basically the problem, except Verso doesn't use any other GUI toolkit. It still uses Webrender to render everything. That's why I tried to find some way to decorate the view. One of the main purposes of this project is to explore Servo's own UI solution.

* how do you envision displaying chrome/system UI that can overlap with browsers, like history suggestions, permission prompts etc. ?

* what will be in charge of displaying the UI elements for the `prompt()`, `alert()` API when called from a browser? Ideally they would match the look and feel of the chrome/system UI of the panel.

We will probably create another type of webview(which is basically a top-level browsing context). I already have another type called context menu in my mind. It should be able to handle the tasks you mentioned.

In Servo that would require implementing a new element (maybe a custom element <web-view>) that can load top level content. I have no idea if that is feasible with the current embedding architecture but that would certainly be an elegant way to build the chrome/system UI. The JS code running in the chrome/system document would also need dedicated APIs to bridge with native code for some features - I feel this is what you're talking about in your last question?

I believe Servo used to have features like this and there was a demo: https://github.com/browserhtml/browserhtml But they removed it due to security concerns. I remember several topics discussed similar to this already, but they all resulted in security issues. What we have right now isn't too bad, IMHO. There are already enough events and messages for the embedder to achieve this. We just need to figure out some more types to make the embedder able to control and composite its webviews.

I hope this clarifies and answers your questions. Thanks for your feedback!

[wusyong]

I just realized the URL scheme of these custom webview (panel, context menu,... etc.) should be chrome:. Servo only serves chrome:blank at the moment. It's definitely possible to expand it. Then, we are able to add the DOM API that should only work in the about scheme or origin.

[webbeef]

Thanks for you response! About the security issue with the <web-view> approach this is more about how this was implemented in Servo at the time than a design issue. As I said, the model itself is proven by Firefox (and Thunderbird, which uses the same way to display html email content): it's absolutely possible to safely isolate the privileged context from the web one. It looks like you will create something much more complex in the end than just implementing a <web-view> element.

[wusyong]

From my experience, the idea of <web-view> element is usually more complex. Chromium deprecated it. Electron also changed their implementation several times. Firefox's chrome UI took years to eliminate XUL, and it's still there in some places. Almost all projects that use moz-central as a framework died except Thunderbird, which also died but got revived recently. So I fear this is a feature that seems easy for users to start with but will end up with terrible maintenance problems. The author of browserhtml did mention the concern of code complexity and security issues. If we really want to bring it back to Servo, I think it's better to open an issue in Servo to justify the reason.

As of now, the design of EmbedderEvent and EmbedderMsg is very clean IMHO. What we can explore are:

• Enum variants that can achieve better IPC (which is the reason for this issue)
• Better control of its Webrender context (which is why I opened https://github.com/servo/servo/issues/32485)

[webbeef]

Firefox's XUL is just a markup language, similar to HTML. It took a long time to switch because XUL had a better box model until flexbox appeared and migrating was a huge task. XUL itself has nothing to do with XPCOM, which people sometimes confuse especially when talking about Firefox "XUL extensions".

Anyway, I agree that we should open a Servo issue - I just hoped you would see the benefit it could bring to this project. I'm convinced it would simplify a lot your UI development, instead of the mix of html panels and direct WebRender access.