Live data from Hacker News

Engineering code quality in Firefox

hacks.mozilla.org

31–40 of 155 posts

Re: Engineering code quality in Firefox

#31

We 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…

Any change to the grading scheme of a class should be Max(old grade, new grade). One of my profs once offered a re-test opportunity such that you would have had an incentive to do worse on the exam for certain original scores. Drove me up the wall.

Re: Engineering code quality in Firefox

#32
post #4

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…

In addition to what others have suggested you might want to check how many things you have registered under about:serviceworkers (type that in as the URL), there might be something in there running far more than is reasonable.

Re: Engineering code quality in Firefox

#33

I am glad they are looking into this: Sorry for the following rant, but I really don't think of Firefox browser when I think of code quality. (Still don't even though it has improved a lot in some areas). When it comes to browsers, I still feel the old Opera browser (presto), that had more features, was blazing fast and small in size (in memory) is a very good example of a finely engineered software. In the early ver…

Presto wouldn't be so memory efficient on today's web; web applications typically ran into plenty of places where memory consumption was worse in Presto versus WebKit, for example. (A simple example here is that each DOM Node was larger in Presto than any other browser, if I'm not forgetting.) But ultimately a lot of this comes down to different considerations: when the majority of your revenue comes from companies w…

> 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 surprisingly well on most websites, though it does show its age a bit). And while the last few versions did seem to be a bit more resource heavy, I attribute that to development suffering because of the upheaval in the company - morale was low as many developers were laid-off while the management was also negotiating a sell out with investors. This naturally stunted the development of the core browsers parts in the end.

(Also, it was a suite and had an integrated email client, IRC, Torrent download manager, RSS reader, apart from the browser, all of which was packaged in a smaller size than Firefox or any other browser of its time!)

> when the majority of your revenue comes from companies who care about running on limited devices, of _course_ the company invested more in running well on them.

True. 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. If I remember right, the first few versions of the Opera browser (then a non-free product) was less than 3-4 MB(2)!

> And I wouldn't hold up Presto as a great example of modularity or the ability to embed the rendering engine in other projects.

I can't comment much about this - The source code of Opera Presto is out there on the net, and it is definitely much easier to understand than the Firefox codebase. I also remember that the popular Macromedia (now Adobe) Dreamweaver used the presto engine at one point.

It says a lot about Mozilla that despite being older than both Chromium / Blink and Webkit, the latter are more popular in many open source and commercial applications because of the ease of use in coding and integrating it in their applications. A good example of this is QT5 which offers the QTWebView and QtWebEngine module (3) that allows you to embed webkit or chromium in your application, out of the box. Whereas qtmozembed is a barely maintained unpopular option for this same use (probably only surviving because Jolla develops their mobile browser for Sailfish OS using it).

(And I suspect this was a deliberate decision made by Mozilla after Gecko / Firefox became a cash cow for them - they just didn't want the code to be modular and easy to understand as it would hinder the creation of competing browsers, which would otherwise potentially cannibalise their own product. Ofcourse, with GeckoView this slowly seems to be changing perhaps on the Android platform, but I cynically suspect this has more to do with the fact that Firefox Mobile is not very popular on the mobile platform, and Mozilla now is looking to encourage developers to create even alternate browsers using their technology hoping it'll provide a filip for their own Firefox Mobile browser. That's certainly going to be interesting to see ... Another intresting tidbit I recall reading somewhere is that Mozilla also makes some developers sign non-disclosure agreements (4) which seems very odd and out of place to me, for an open source project.)

(1): https://en.wikipedia.org/wiki/Presto_(browser_engine)

(2): https://filehippo.com/download_opera/8.02/

(3): https://stackoverflow.com/questions/29055475/qwebview-or-qwe...

(4): https://medium.com/@smsnobin77/firefox-build-macos-f1f53d643...

Re: Engineering code quality in Firefox

#34
post #31

We 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…

Any change to the grading scheme of a class should be Max(old grade, new grade). One of my profs once offered a re-test opportunity such that you would have had an incentive to do worse on the exam for certain original scores. Drove me up the wall.

I also think that just keeping the new grade is a valid retake scheme. Although it's less forgiving for the students, it encourages them to make absolutely certain that they know the content for the retake. Anything with a square root curve where you have to pinpoint your retake score perfectly to maximize the final grade is unfair and encourages the wrong thing.

Re: Engineering code quality in Firefox

#35

Earlier quoted context omitted.

That makes no sense as a class design - are there so many zero days in firefox that are so easy to find that you can expect undergrads to casually find enough that you can base 70% of the class grade on it?

Every teacher wants to be the next Jaime Escalante. Sometimes they take their idealism too far.

I'm gonna go out on a limb and say that a research professor at presumably a large research university doesn't give two shits about being the next jaime escalante. The reality is probably that they're more focused on research, and don't care much about actually teaching. You see quite a bit of that.

Re: Engineering code quality in Firefox

#36
post #9

Earlier 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.

Because the entire advantage of the web from the perspective of the end user (as opposed to desktop applications) is that you can expect it to work the same everywhere. If everything were separated, it wouldn't make a difference, because Chrome and MobileSafari will continue shipping one integrated stack, even if they're forced to open up APIs for modularity.

What tangible advantage would this have? Having competing browsers seems possible, but since end-users wouldn't be choosing individual browser components anyway, it wouldn't actually improve anything.

Re: Engineering code quality in Firefox

#37
post #15

Earlier quoted context omitted.

What doesn't a browser do these days.

Email! For now ;) http://catb.org/jargon/html/Z/Zawinskis-Law.html

It does effectively. With Gmail at least, there's an option to register Chrome as the mailto handler. Anytime you click on a mailto link anywhere on your computer, it will open Chrome to the compose window in Gmail. And Gmail works offline, so it's not really any different from having a traditional email client built into your browser.

Re: Engineering code quality in Firefox

#38

Earlier quoted context omitted.

Presto wouldn't be so memory efficient on today's web; web applications typically ran into plenty of places where memory consumption was worse in Presto versus WebKit, for example. (A simple example here is that each DOM Node was larger in Presto than any other browser, if I'm not forgetting.) But ultimately a lot of this comes down to different considerations: when the majority of your revenue comes from companies w…

> 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…

> 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).

Re: Engineering code quality in Firefox

#39
post #30

I am glad they are looking into this: Sorry for the following rant, but I really don't think of Firefox browser when I think of code quality. (Still don't even though it has improved a lot in some areas). When it comes to browsers, I still feel the old Opera browser (presto), that had more features, was blazing fast and small in size (in memory) is a very good example of a finely engineered software. In the early ver…

Opera felt small and fast because it did less and ran websites doing less. If you look at an old site in a modern browser, it's much faster; if you even could run a modern site in an old browser, you'd see just how many optimizations you're taking for granted — not to mention things like high-quality text rendering which fully supports Unicode and complex scripts.

> Opera felt small and fast because it did less and ran websites doing less.

Let us assume that is true (even though it isn't) - what's Firefox and other browsers excuse for running slower than Opera on these same sites, during the same period?

Opera presto supported a lot of the features of HTML5(1). So it didn't necessarily "do less" than the others.

And second, if you really want to compare Opera presto with other browsers, you should do it with the versions of the competing browsers that were available then. (I still remember how people complained about Firefox consuming a a lot of RAM when you opened more than 10 tabs, where as Opera could easily handle 100+ tabs(2) without any complaints.)

Even otherwise, if you test it out yourself today by downloading an Opera presto version (version 12.15 / 12.16) you will find how usable it still is on 70-80% of the websites today, even after not being developed for years now).

(1) https://en.wikipedia.org/wiki/Presto_(browser_engine)

(2) https://forums.opera.com/topic/19313/how-to-retrieve-acciden... ... and ... https://portableapps.com/node/59581

Re: Engineering code quality in Firefox

#40

I am glad they are looking into this: Sorry for the following rant, but I really don't think of Firefox browser when I think of code quality. (Still don't even though it has improved a lot in some areas). When it comes to browsers, I still feel the old Opera browser (presto), that had more features, was blazing fast and small in size (in memory) is a very good example of a finely engineered software. In the early ver…

I second your opinion. I used to give Firefox a tremendous amount of leeway because its support for extensions and customization set it head and shoulders above competing browsers. Now that they've thrown away that advantage I find myself using alternatives more and more.
Post reply on HN