Plasma on the Edge

You probably have heard the news by now that Microsoft have released the Linux version of their new Chromium-based Edge web browser. Of course I’ve been waiting for this day ever since they announced the switcheroo to Chromium in order to bring Plasma Browser Integration to Edge users. It took Microsoft almost two decades to offer another web browser to a Unixoid desktop and this time around it’s based on KDE’s legacy – what a time to be alive!

You can already use Plasma Browser Integration just fine with Edge by installing it from the Chrome web store. Until Plasma 5.21 is out, however, it will only see it as yet another Chromium, meaning that KRunner, media controls, and so on might not map to the correct browser window or show only a generic icon.

I’ll look into getting it listed on the Edge extension store, too. If you’d like to help with that or even maintain our future store presence there, please get in touch!

Using CGroups for browser identification

The binary that runs in the background bridging the extension to your Plasma desktop has to impersonate the browser, so that for example a download job in notifications shows the correct application icon. Currently this is done using a heuristic based on user agent and parent process name. Doing that is somewhat brittle and needs to be updated whenever a new browser shows up and can’t tell the difference between stable, developer, and nightly builds. Since I can’t know what desktop file name the release version of Edge will eventually get – will it have a “stable” suffix to match the “dev” version or not? – I was looking for a way to get the browser identity some more generic way.

Fortunately, Plasma nowadays launches applications in their own cgroups, and since the bridge is started by the browser, it will be in the same cgroup as it. This way I can just look up the relevant browser desktop file from there and set a matching application name and icon by merely reading from that file without having to worry about distribution-specific packaging, special release flavors, or keeping a heuristic up to date.

I haven’t tried it with anything but Edge yet but I’m fairly certain once this change is merged it should be able to identify Firefox nightly as well as work properly with pretty much any Chromium-based browser that supports Web Extensions. This approach is yet another great example of how leveraging modern infrastructure can reduce maintenance cost and future-proof a project. Nevertheless, I’ll keep the old heuristic in place for compatibility and extend it to go looking for an “msedge” binary, too.