I’ve been using Firefox almost exclusively since at least October 2002, when it was known as Phoenix 0.3. It is the only modern browser developed by a non-profit foundation with the goal of keeping the Internet an open platform. It is fast, it usually needs less memory than other browsers (especially with many tabs open), it has pretty good developer tools and it is officially supported on Windows, macOS and Linux, as well as Android and iOS – there are also inofficial ports for other operating systems like FreeBSD, NetBSD and illumOS.

Unfortunately, its market share kept decreasing since the release of Google Chrome, and I think there are some areas where it falls behing other browsers, from a technical perspective.

Security

Modern browsers are extremely complex software that need to display untrusted content from the Internet and, in the case of JavaScript, execute it on the local machine. Although the number of security vulnerabilities in 2016 has been comparable among browsers, the advanced sandboxing techniques that Chrome employs only allowed remote code execution in around 2% of vulnerabilities (this figure lies at 40—60% for the other browsers). Until recently, Firefox was the only browser to sandbox only the plugins, but not the web content; this is work in progress.

Multiprocess web content

Firefox recently added support for running web content in separate processes. Unlike Chrome or Safari, it doesn’t run each tab in a separate process (this would be needed for better sandboxing and interactivity, but it increases memory consumption). Firefox currently uses 1 or 2 web content processes, which should at least allow the browser to remain responsive if something bad happens in a tab.

Unfortunately, as I discovered while investigating a memory leak in Jenkins CI, Firefox completely stops responding, making it impossible to close the problematic tab – I had to kill Firefox using the process manager of the operating system before it could trigger an out-of-memory event. Chrome and Safari remain responsive the whole time, and closing the “bad” tab works immediately, without any issues.

Without being familiar with the Firefox code, I can only speculate that its user interface will stop responding when the JavaScript engine is under memory pressure and needs to run the garbage collector the whole time (the Firefox user interface is implemented in XUL, being rendered just like a web page; this is not the case for the other browsers).

Developer Tools

Chrome’s Developer Tools can track the number of allocated DOM nodes; a single click on the graph showing the increase in the number of nodes will display the full stack trace of the JavaScript code that allocated them, and it can then open the offending JavaScript code in the debugger, positioned at the correct line. Finding the cause of the Jenkins memory leak took just seconds in Chrome, after several hours of fruitless debugging in Firefox (to be fair, Safari doesn’t have that functionality either).

Memory consumption

Firefox used to have an advantage on older computers due to using less memory than Chrome. That seems to have changed during the last few releases: while the Firefox memory usage slightly increased, Chrome now needs 100-200 MB less than Firefox, with the same set of open pages. Maybe Google’s efforts to reduce memory consumption in Chrome are producing visible results.

Back to posts