A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

[Proposal] Browser Display Server Mode protocol

SoniEx2
2020-12-29

Electron is great, because it ships a whole separate browser with your app.

Why not integrate electron into the browser then? You still get to have your separate app, but you can just use a tab in the existing browser.

Easy way to do this is to bind on localhost port 0, and then xdg-open (or platform equivalent) the resulting address. (e.g. xdg-open http://localhost:1234/?secureKey=some-key-that-needs-to-be-sent-over-CORS-enabled-HTTP-authentication) This can also be trivially SSH-forwarded. In other words, it’s better than X11 already. You can then interact over websockets with this.

There are a few minor issues with the http-to-localhost approach that can be fixed by introducing a new protocol tho. Mainly, the CORS/secureKey workaround. It shouldn’t need to exist. Additionally there’s the issue of port numbers and the interaction between port numbers and push notifications. (the interaction with protocol handlers is a non-issue because you should just use the OS-level protocol handlers for that one. altho arguably one should just use the platform-specific notification APIs because they’re rather limited in what they let you do unlike what GUIs let you do? (like, you can’t run OpenGL in a desktop notification.)) Oh, and copying buffers over websockets, such as when displaying OpenGL-rendered content, is slow. (Arguably should be using WebGL, but ehh…)

A small benefit of a new protocol would be that the browser could act like a proper display server when using said protocol - setting the window icon, removing browser-specific decorations, etc. While still allowing browser extensions (and thus themes and content blockers) to apply somehow.

Does this seem like something worth specifying?