| HN Mirror

I worked on the cross platform TomTom Home content management app in 2007-2008, which used XULRunner and XP/COM extensively.

But XULRunner only really existed to serve Mozilla's Firefox web browser, and anyone using it for their own applications, like TomTom Home or Songbird, was on their own without any support.

Mozilla didn't take our XULRunner PRs seriously, or put much more than promises and lip service into XULRunner supporting other applications than Firefox.

https://en.wikipedia.org/wiki/TomTom#Support_applications

https://en.wikipedia.org/wiki/Songbird_(software)

If Mozilla was actually serious about supporting XULRunner for anything but Firefox, then it might have taken the place of Electron a lot earlier that Electron's release in 2013. That was a huge missed opportunity and tragedy of broken promises and wasted effort.

https://news.ycombinator.com/item?id=7601083

>I first looked at Red Swoosh and its Firefox extension, FoxTorrent. It would have been ideal, since we using the xulrunner platform for TomTom Home, but Akamai acquired Red Swoosh, and it vanished without a trace. [...]

https://news.ycombinator.com/item?id=20140349

>One way to get Akamai to unilaterally lower their bandwidth prices is to threaten to use BitTorrent instead. [...]

>TomTom had an "iTunes-like" desktop content management and device control desktop app called TomTom Home, which was implemented in xulrunner (the underlying framework of Firefox and Thunderbird, kind of a predecessor to Electron for writing cross platform desktop apps in JavaScript with C++ XP/COM plugins).

>The first thing I tried was to make an XP/COM plugin out of the LibTorrent library. That worked ok, but the idea of increasing the size and complexity of what was already essentially a web browser with a whole bunch more complex code that does lots of memory allocation and networking all the time, didn't seem like a good design. This was long before Firefox supported multiple processes, so the same app handing bittorrent would bloat the app and degrade the user interface responsiveness.

>However RedSwoosh, FoxTorrent and BitTorrent DNA all ran in separate processes that just handled all the BitTorrent stuff, and that you could talk to via https (to stream the file with a special url, and retrieve progress telemetry on another url). And it's incredibly easy to integrate xulrunner or any web browser with those servers via http, so no C++ XP/COM plugin required.

>Another issue is that you don't want every application to have its own BitTorrent client built in, or you will trash the network and disk, since otherwise they would compete for resources. It needs to be a centralized a system service, shared by any app that needs it.

>BitTorrent DNA worked nicely that way. And it could fall back to the CDN to download at full speed if there weren't enough seeders.

Also unfortunately, XULRunner was in no shape to run on mobile or embedded devices, so we ended up running WebKit on the TomTom embedded Linux devices, instead of trying to shoehorn Mozilla into small mobile devices.

https://news.ycombinator.com/item?id=34227548

>Both Chrome and Safari were based on WebKit (which itself started as a fork of KDE's KHTML and KJS libraries), which a lot of other vendors use too.

>Although Chrome eventually diverged years later with the development of Blink, Chrome was the result of a multi-company, industry-wide unification strategy on WebKit, the core of Safari. [...]

>Mozilla was in no shape to run on mobile or embedded devices (and still isn't afaik), while WebKit ran quite nicely on mobile and embedded devices, thank you. And as we all know, Android is as important to Google as iOS is to Apple.

>So there was really no chance of either of them (or any other of the many companies interested in mobile and embedded devices, like TomTom for example) ever building on top of Mozilla/xulrunner.