I was thinking about Firefox development quality while trying to figure out why the f does Firefox CPU usage fluctuate between 1 and 5% with one background tab open and only one plugin installed (containers). The same URL when opened in safari goes to 0.1% or 0.0. I tried to look up dom timeout config settings and tried to set aggressive timeouts, but in the end I gave up. There must be something fundamentally wrong…
Chrome has the same issue. The thing is, Safari is deeply connected to OS X and its internals to save as much energy as possible. Apple can do this and tie the code to the specific hardware, kernel, and what else matters that Safari runs on as they control everything. Chrome and Firefox cannot. I would not be surprised if someone tells me that parts of Safari hook into private APIs in the kernel, the graphics driver…
Engineering code quality in Firefox
51–60 of 155 posts
Re: Engineering code quality in Firefox
#52Earlier quoted context omitted.
the f does Firefox ... same URL when opened in safari It would be interesting to compare the safari budget/manpower. Even given that, I would imagine safari only has to support one-ish OS, and probably has help from the OS group.
The WebKit team is smaller than the corresponding team at Mozilla, even if you look at the subset of of identical roles across both organizations (and e.g. ignore those working on the Firefox network stack). That said, it's worthwhile remembering that WebKit does very much maintain all the abstractions to be cross-platform (and Apple do still maintain a Windows port), even if it does try and leverage plenty of OS lib…
Re: Engineering code quality in Firefox
#53Earlier quoted context omitted.
I think you’re underestimating what browsers do. They have an incredibly performant and highly-tuned VM, an extremely flexible and powerful layout engine, a comprehensive set of media players, and that’s not even talking about networking, security, and UI.
This seems to scream "separate me!". Why is it acceptable to put all this responsibility into one giant ugly ball? We desperately need separate layout engines, parsers, renderers, etc. Assemble-your-own-browser.
Choice matters. Sometimes you have to make a choice on behalf of your users. I think that’s what the industry as a whole has done here. Nothing is preventing people from rolling their own modular web browser. Maybe things like Beaker Browser and TOR Browser are versions of that same idea but approached from a specific use case.
Thanks for this comment. I think your idea is good but not for the same reasons that a web browser suite is a good idea for most non-technical users.
Re: Engineering code quality in Firefox
#54Earlier quoted context omitted.
> The source code of Opera Presto is out there on the net I don't suppose it's been open-sourced, has it? It would be great to have an alternative browser engine out there, instead of just three (or two and a half, depending on how you count Blink and Webkit).
> I don't suppose it's been open-sourced, has it? No, it was leaked illegally. Opera filed a lot of DMCA complaints with many online Git repository services to get the code removed from them. But you can still find it if you Google hard. I also recall reading that some Russian developers were working on the leaked code and had also released a "newer" version with some patches (Opera presto was really popular in Russi…
Re: Engineering code quality in Firefox
#55We had an "open-ended" project in an undergraduate Computer Security course to discover a 0-day in Firefox. The professor (a researcher, not lecturer, by trade) didn't really have a curriculum, and said this artifact accounted for 70-80% of our grade. Trying to compile Firefox was already a challenge. That, and each compile took an hour. IIRC, Firefox is built on some esoteric architecture / design pattern that's def…
Things are much better these days, but there is still much inherent complexity in a project like Firefox.
Re: Engineering code quality in Firefox
#56Earlier quoted context omitted.
Email! For now ;) http://catb.org/jargon/html/Z/Zawinskis-Law.html
remember Opera and Seamonkey (and Lotus Notes) back when the all-in-one email/browser/cal/notes application concept was still kicking
You mean Emacs? All it needs is a good editor :)
Re: Engineering code quality in Firefox
#57Earlier quoted context omitted.
The WebKit team is smaller than the corresponding team at Mozilla, even if you look at the subset of of identical roles across both organizations (and e.g. ignore those working on the Firefox network stack). That said, it's worthwhile remembering that WebKit does very much maintain all the abstractions to be cross-platform (and Apple do still maintain a Windows port), even if it does try and leverage plenty of OS lib…
Who uses WebKit on Windows?
Re: Engineering code quality in Firefox
#58> Our next major challenge: We are dealing with 21 million lines of code. I think I just fail to understand the true complexity of a browser, but how is Firefox 21 million lines of code? How can a browser be 21 million lines of code? That just seems so large for what a browser does.
Re: Engineering code quality in Firefox
#59I was thinking about Firefox development quality while trying to figure out why the f does Firefox CPU usage fluctuate between 1 and 5% with one background tab open and only one plugin installed (containers). The same URL when opened in safari goes to 0.1% or 0.0. I tried to look up dom timeout config settings and tried to set aggressive timeouts, but in the end I gave up. There must be something fundamentally wrong…
Things (on the same constrained resources VDI) get even worse with actual "complicated" content: viewing the same page which contains an animated GIF, Firefox seems to prioritise playing back the content, even at the expense of noticing/obeying user-interface interaction like closing tabs and opening menus: i.e. gifs will keep playing (very slowly), but it won't notice UI clicks on its interface for many seconds seconds.
In the same scenario, Chrome responds to UI events much more quickly (very nearly instantly).
It's possible this is due to hardware acceleration or something, but as both are running in the same VDI that barely seems to have OpenGL 2.0 support (I can't run modern OpenGL apps), that seems unlikely to me...
Re: Engineering code quality in Firefox
#60Earlier quoted context omitted.
> Presto wouldn't be so memory efficient on today's web; I disagree. (I continued to use the last version of Opera Presto for a few year even after it was abandoned, and it continued to outperform other browsers on both platforms - Windows and macOS, though the macOS version was a bit more buggy). Let's not forget that Presto already supported a lot of HTML5 features(1) before it was abandoned. (Even today, it works…
> But let's not forget that Opera browser earned its reputation for being blazing fast, its tiny size and its low memory consumption on the desktop platforms long before it became a popular browser on the mobile platform. Just about all of the major browsers earned their reputation for being blazing fast, tiny, and using little memory. And those attributes are well-deserved at their launches. Then real-world pressure…
Not like Opera though who made performance and small size (and power optimizations) as their core philosophy.
(This was the browser whose popularity even frightened Microsoft, whose infamous Internet Explorer had I think nearly 80% market share at the time. So much that they deliberately ensured that their website broke on Opera. And it forced them to reluctantly focus on the Trident engine that powered IE again - till then, they had been ignoring IE because Microsoft was rightly genuinely frightened of competing on and with the web).
Starting with the mindset of making a fast, small and efficient engine that could run on constrained systems was the reason Presto outshined other engines. Later this extended to optimising their code for lower power consumption too.
That's the main difference with Gecko, Chromium / Blink and Webkit (to a lesser extent) who did focus on optimising for speed but were a bit more lax on the memory and power aspect and only started addressing it after users started complaining (and ofcourse, only after they made mobile platform a priority). I still remember how we users grumbled when Opera installers crossed the 10 MB size :) ... but Opera still managed to keep us hooked by introducing a plethora of features while still trying their best to maintain an efficient code base and deliver it in a smaller package. Compared to it, equivalent versions of Firefox and other browsers at that time (and even today) seem very bloated in comparison because it's not a priority to them.
> Then real-world pressures kick in -- it turns out that although people love small and fast, that doesn't do them much good without support for X (or being able to handle condition Y), and there are many, many values of X (and Y).
Sure, but this doesn't apply to Opera. Opera kept their high standard and core philosophy intact till the last version before management failed them. It maintained feature parity with competing browsers till the end, before it was sold off and dumped for Blink to cut costs.
Opera didn't fail because it couldn't keep up with web standards or in introducing new features, but because of poor business management.
If Opera's founder is to be believed, they just couldn't allocate enough resources for keeping track of, and patching broken popular sites that don't follow web standards. (This is the reason he gave for abandoning Presto, and selling his company, and then choosing Blink for his new Vivaldi browser).
Opera the business failed, but their product was top notch and better than their competitors till the end. If I remember right, I stuck with it till 2017-18 before I moved on to Firefox and later to Ice Cat, Pale Moon and Safari.
> We [I work for Mozilla] end up mainly competing on different metrics, assuming we all keep up with "good enough" speed and size.
Yeah, that's spot on - that's what I've always felt about Firefox, that Mozilla's philosophy is to be "good enough", and that's why to us consumers the product (Firefox) feels "average". There is nothing much to feel excited about in terms of performance or features. That's the area (performance and features) that Opera excelled in.
> And yes, it was a deliberate decision, but not for the profit motivations you're suggesting.
I am sorry but I don't believe this - it was very much for profit too. I do believe it was to ensure the project isn't forked easily to build a competing product. Just look at Goanna / Pale Moon struggling to maintain quality and feature parity now. (Ofcourse they are also struggling because of the design decisions they made).
Chromeless Firefox was a very interesting project. Killed before it could become popular. Vivaldi browser is based on a similar idea and its enjoying some success.
My point is that it is a smart decision from a purely business perspective - look at all the relatively successful fork of the Chromium browser. And browsers based on webkit. There are many people who don't like the current direction of Mozilla and / or Firefox and they would gladly jump on to decent a fork if it were easy to do so.
> It was based on maintainability and developer velocity, when we realized we were not going to out-compete Google with engineer headcount. We had to simplify and reduce our nonessential complexity overhead.
That's MBA manager speak - lots of buzzwords that don't really convey anything meaningful. ;)
My perspective is that as an open source project, Mozilla shouldn't sacrifice product quality for short-term gains. They should fix bugs rather than focusing on new features or products even if they lose ground to other browsers. Their focus should be on quality rather than trying to compete with a corporate product and keep pushing release after release just for the sake of competing and "staying relevant".
> Why throw so much shade? ... we have very little to gain from keeping any technical or architectural stuff private, and quite a bit to lose.
That is exactly why I found it interesting that an open source project was asking volunteers to sign NDAs! (https://medium.com/@smsnobin77/firefox-build-macos-f1f53d643...)
As for the snark against Mozilla - your perception is right. I do have a certain level of antagonism against the foundation. It stems from the following reasons:
(1) They are a million+ dollar foundation and still produce an "average" product. Comparing them to other open source projects with much, much smaller budgets that produce high quality softwares really irks me.
(2) Some of their recent management decision range between foolish to greedy. E.g. Forcing Pocket on unsuspecting users (I strongly suspect some members where bribed to push this integration). E.g. Including closed source DRM in the browser (if users want to download a plug-in to watch DRM protected media, then they should have a choice to do so. Google and Cisco, if I remember right, now have a monopoly on this because of Mozilla).