3 ms·
(I worked on Firefox for 9 years) > Why is libxul a shared library? A lot of this is historical and is now very difficult to change without negatively impacti
by dblohm7 3y ago
(I worked on Firefox for 9 years)
> Why is libxul a shared library?
A lot of this is historical and is now very difficult to change without negatively impacting users.
> It is not used by a bunch of other applications besides Firefox so there isn’t much saving from being shared.
In the 2000s it was designed to do so, via XULRunner. You're also forgetting about Thunderbird and SeaMonkey (though I don't think that either of those can actually share libxul.so with Firefox anymore, but I digress).
But as to why it is the case now, there are still compatibility considerations that fall out from the era when Gecko+XUL were written as a runtime environment for hosting applications.
For example, I recall that during the Electrolysis project, we wanted to get rid of the plugin-container executable on MacOS and just host all Firefox child processes using firefox. Some "security" software would break Firefox because it made certain assumptions about the way that various Firefox binaries interacted with each other.
FWIW, Gecko used to consist of a lot more separate libraries, but over the years we recognized that there were a lot of performance issues that we could mitigate by combining them, so most shared libraries were folded into libxul.
- smnrchrds 3y agoTo add to this, there were a few cool XUL-based software out there back in the day: Songbird, ActiveState Komodo IDE, Zotero, etc. XUL didn't take over the world like Electron, but for a moment it felt like it could.
- mschuster91 3y agoIt was both too late and not early enough. I 'member back in the VB6 era that you could easily embed Internet Explorer as an ActiveX (or was it OLE?) element right inside your application - a very early sort of WebView, just with absolutely no way to inspect what was going on there. I think Firefox never achieved a 1:1 compatible match for that... despite Microsoft keeping that utter shit around for ages for compatibility reasons as a lot of apps used it under the hood (e.g. HTML Help). And yes you could absolutely do a Matroshka with it: a VB6 app embedding Internet Explorer and the site embedding an ActiveX element written in VB6. Or inline Java applets. Funny times... an era in which security was barely a concern. Instead, you had open-ish, usually well documented interfaces for everything. What killed the idea though until Electron came along was simple: Browsers didn't even come close to feature parity. You had to write your own API layer to communicate between the website and the host application for everything going beyond XHR calls and file selector uploads. Electron took off once Chrome got enough native bridges that you could actually write capable web apps.