15 ms·

Engineering code quality in Firefox

296 points by caution 6y ago

unethical_ban 6y ago
I appreciate the acknowledgement of needing to tolerate previously acceptable conditions while scanning and remediating those same conditions point forward. I wish IT auditors understood this concept better.
rstefanic 6y ago
> 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.
- NikolaeVarius 6y ago
  What doesn't a browser do these days.
  - gen220 6y ago
    Email! For now ;) http://catb.org/jargon/html/Z/Zawinskis-Law.html http://catb.org/jargon/html/Z/Zawinskis-Law.html
    - 2fifty3 6y ago
      remember Opera and Seamonkey (and Lotus Notes) back when the all-in-one email/browser/cal/notes application concept was still kicking
      - rhinoceraptor 6y ago
        > all-in-one email/browser/cal/notes application concept You mean Emacs? All it needs is a good editor :)
    - snazz 6y ago
      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.
- spyridonas 6y ago
  Chrome is 25M, so they are close. Yeah i think its too much as well.
  - the_arun 6y ago
    Seems like modern day browsers are not just HTTP Client, they are close to an Operating System. But still surprised by size of LOC.
- thinkharderdev 6y ago
  It doesn't seem that crazy to me. Calling them web browsers is kind of anachronistic at this point. Just the JS engine itself seems like it would be massively complex. It's a VM with a JIT compiler which I can only imagine is quite cumbersome to implement securely
- jdlshore 6y ago
  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.
  - mrmonkeyman 6y ago
    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.
    - snazz 6y ago
      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.
    - aspenmayer 6y ago
      It sounds like a good idea to be implemented by a technical user, and a solution looking for a problem to every other kind of user. I thought dependency hell was bad but this sounds like a further circle of such hell. I like that I can tell a user to just update their browser and OS and be confident that most users will handle the operation thereof. I know how to tell a non-technical user how to update their web browser in words they can understand. I’m going to have to write a new script for how to explain the scope of the limitations of using a web browser as a compiled application versus the proposed modular architecture just so they can tell me they don’t want or need that. 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. https://beakerbrowser.com https://beakerbrowser.com
- kryptiskt 6y ago
  A browser lays out text and graphics (for any script in any locale), does GPU accelerated 3D rendering, handles network communication, plays video, plays audio, provides accessibility, parses a bunch of languages, compiles a couple of languages to machine code run in a security sandbox (and has a separate optimizing compiler), provides database storage, implements a plugin system, provides support for 25 years of legacy standards. And a bunch of more things.
  - ken 6y ago
    It also reimplements all of those things itself from scratch because their priority is on cross-platform parity, not efficiency. Every time I see someone working on a FF bug I’m cc’d on, I marvel at how many files they have to touch to get anything done. One key binding missing, because they’re not using the system text field? Hundreds of lines of diffs, spread across a dozen source files.
- vkou 6y ago
  Having worked on codebases that are more than 10 million LOC, I'm surprised that Firefox's functionality fits into such a small amount of code.
- aschatten 6y ago
  Modern day browsers are essentially VM with rich customizable GUI.
  - skohan 6y ago
    This is something I really deplore about the state of modern software development. Taken collectively, it's mind-boggling the amount of waste there is in terms of memory and CPU (i.e. energy) usage by running a huge portion of consumer software in the browser. We could achieve the same result so much cheaper, with better performance and UX, by putting a serious effort into a set of standards for handling code from an arbitrary source securely.
    - Epskampie 6y ago
      > a set of standards for handling code from an arbitrary source securely That is what html+js is. Why do you presume a different standard would be more efficient in the end?
      - skohan 6y ago
        HTML+ECMAScript keeps the developer at quite a distance from the hardware, and it imposes all kinds of limitations which don't have to exist. The web is good enough for pure content delivery, but for more advanced interactive applications, the limitations are a huge waste. For instance, I have a computer at home with a 12-core, 24-thread processor, but web applications are basically single-threaded with some very limited support for web workers. I'm also limited to basically one language, which is garbage collected, so performance and memory usage are significantly worse than they could be. And as far as graphics, you're limited to WebGL which is ages behind the state of the art in terms of graphics APIs. Basically there is a whole universe of tools out there for software development, but if you want to target web you're limited to a handful of poorly performing, hacky options. For my work, we use several web applications to collaborate. As someone who works on highly optimized user-facing software, it's frustrating to understand how poor these web applications perform given the potential of modern hardware. The reason we use them is because you can send anyone a link, and they're into the software in one click. There's no reason we couldn't have the same experience for native software, where when you click the link your computer downloads a native binary and runs it in a sandboxed environment against a standardized system API. It would take a lot of careful work and planning, but there's no technical reason it couldn't exist, and it would be so much better for developers and users.
- oreally 6y ago
  This LOC count is going to be a huge problem in the future, and you'll see it as the bug count climbs. It'll be hard for people to understand how the system works and hard for them to ramp up. You'll see the slow decline if there's ever a point in which their funding is reduced and employees have to be laid off.
djanogo 6y ago
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 if apps can't stfu and be at 0% while in background with simplest use case. I am going back to close app's when I am done using it.
- mschuster91 6y ago
  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 and the other parts of the graphic and input stack to achieve the (measurable!) performance advantage over other browsers. For me personally, this is uncompetitive behavior that should be punished, but oh well, anti-trust legislation isn't exactly something that got much use over the last decades :(
  - paulryanrogers 6y ago
    Doesn't Safari also lag in implementing new or battery-hungry features? I suspect that could be a big factor too.
  - _startingover 6y ago
    The rendering engine is open source. You’re welcome to audit it here: https://webkit.org/getting-the-code/ https://webkit.org/getting-the-code/
  - spijdar 6y ago
    You think Apple should be punished for creating a vertically integrated stack? Setting aside private APIs as I have no idea what Safari does or doesn't use (although vast portions of it are open source, enough that you can compile modern versions of WebKit and "upgrade" the ancient WebKit on PowerPC Macs), another browser could be just as closely integrated as Safari. Obviously, the cost/benefit ratio is awful for Mozilla and Google, so they won't, but why should Apple cripple their own software? Safari's development costs, as part of MacOS, are funded by profits from Mac sales. Safari is deeply integrated with MacOS which is in turn deeply integrated with the Mac. In my opinion the whole point of the Mac is this vertical integration, and the main value-add of Apple's sphere. If you don't value that, there are cheaper options where cheaper and more flexible software is available. To me, an anti-trust suit would make sense for Safari on iOS, where Apple has locked all competitors out (in practice). Saying Apple should be fined for Safari because it's more integrated and efficient and that's not fair to Chrome and Firefox seems a bit silly, especially given (desktop) Safari's relatively small usage numbers. All IMO of course.
webmobdev 6y ago
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 versions they really cared about optimizing for performance, using less memory and less power (on mobile devices) - I am amazed that years after, modern browsers are bloatier now than ever and just don't seem to care as much about these aspect as much as Opera did. Questions like how modular is Firefox, how easy is it to customize Firefox (add or remove feature from the code), how easy is it for someone to use the Gecko rendering engine in their own project etc. all kind of indicate the bloatier, messier nature of the code within Firefox (in my opinion). It's like browser developers now a days only care about adding more features (read bloat) without considering any constraints ...
- gsnedders 6y ago
  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 who care about running on limited devices, of _course_ the company invested more in running well on them. And I wouldn't hold up Presto as a great example of modularity or the ability to embed the rendering engine in other projects.
  - webmobdev 6y ago
    > 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) https://en.wikipedia.org/wiki/Presto_(browser_engine) (2): https://filehippo.com/download_opera/8.02/ https://filehippo.com/download_opera/8.02/ (3): https://stackoverflow.com/questions/29055475/qwebview-or-qwebengineview https://stackoverflow.com/questions/29055475/qwebview-or-qwe... (4): https://medium.com/@smsnobin77/firefox-build-macos-f1f53d643e81 https://medium.com/@smsnobin77/firefox-build-macos-f1f53d643...
alephnan 6y ago
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 definitely beyond the scope of design patterns undergraduate students are familiar with. By the end of the term, no one discovered a 0-day, unsurprising considering half the class didn't even try. There were 90 students in the class, and I ended up being the only person to produce a JS payload that would crash Firefox in one of the newer HTML5 libraries. It's neither a zero-day or exciting or profitable vulnerability though. Realizing everyone in the class would fail, the professor changed the grade of this project to only account for 30% of the grade. I spent most of my time on this project while disregarding the rest of the busy work for the class. In the end, I got a C grade while my peers who didn't even attempt to tackle this project received higher grades.
- freeboson 6y ago
  The syllabus where a grade is broken down by percentages is (at US institutions) considered to be like a contract. If the course originally had it at "70-80%", then it cannot be changed mid-semester without being acceptable to you. It's fairly incredible for this to happen (at a US institution).
- totony 6y ago
  Whenever you have trouble compiling something, just look at how gentoo approaches it. They're the last bastion making sure OSS is actually buildable. Them are their users most likely are the #1 source of build documentation, bug reports and fixes in OSS
- vikramkr 6y ago
  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?
  - 6y ago
worker8 6y ago
a
bergheim 6y ago
I just wanted to say that, despite a few mishaps, firefox is what _everybody_ on hn should be using. I can give my browser-time credentials, but really. Firefox is amazing. Care for the open web, fear ie6, and at the same time enjoy firefox!
- eitland 6y ago
  > Care for the open web, fear ie6, and at the same time enjoy firefox! And remember: Chrome is the new IE. (Since a number of people have misunderstood this quote in the past I'll explain it up front: 1. IE was in some ways technically superior to competition until they became dominant. 2. At the same time devs stopped caring about other browsers, and then 3. Microsoft lost interest in it. We are repeating this it seems, currently at step 2 for a few years already, waiting for Chrome to completely outcompete other browsers and for Google to abondon it like so many other of their projects :-) Edit: I took the time to write down a slightly expanded version of the explanation above: https://erik.itland.no/chrome-is-the-new-internet-explorer-4-stages https://erik.itland.no/chrome-is-the-new-internet-explorer-4...
  - deleted 6y ago
    [deleted]
  - alephnan 6y ago
    For people who don't care about privacy, what would be the motivation for making the switch? Chrome is good enough. The interface is still streamlined. Microsoft didn't just lose interest in IE, but it became bloated with the toolbar. The UI wasn't well proportioned in general. Web development wise, it was a struggle to be compatible with IE. Chrome may be setting the web standard for better or worst, but atleast developers are more comfortable developing and testing Chrome. The sentiment is that writing code to work I.E. would be exceptional, whereas now writing code for non-Chrome browsers would be the exceptional case. In fact, developers sometimes only test Chrome. Some popular E2E JavaScript testing frameworks only work with Chrome. Also, I don’t know if there are examples of Chrome implementing non-standard behavior that rivals IE having an event bubbling system that was inverted from every other browser.

296 points by caution 6y ago

I appreciate the acknowledgement of needing to tolerate previously acceptable conditions while scanning and remediating those same conditions point forward. I wish IT auditors understood this concept better.

rstefanic 6y ago

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

NikolaeVarius 6y ago
What doesn't a browser do these days.
- gen220 6y ago
  Email! For now ;) http://catb.org/jargon/html/Z/Zawinskis-Law.html http://catb.org/jargon/html/Z/Zawinskis-Law.html
  - 2fifty3 6y ago
    remember Opera and Seamonkey (and Lotus Notes) back when the all-in-one email/browser/cal/notes application concept was still kicking
    - rhinoceraptor 6y ago
      > all-in-one email/browser/cal/notes application concept You mean Emacs? All it needs is a good editor :)
  - snazz 6y ago
    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.
spyridonas 6y ago
Chrome is 25M, so they are close. Yeah i think its too much as well.
- the_arun 6y ago
  Seems like modern day browsers are not just HTTP Client, they are close to an Operating System. But still surprised by size of LOC.
thinkharderdev 6y ago
It doesn't seem that crazy to me. Calling them web browsers is kind of anachronistic at this point. Just the JS engine itself seems like it would be massively complex. It's a VM with a JIT compiler which I can only imagine is quite cumbersome to implement securely
jdlshore 6y ago
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.
- mrmonkeyman 6y ago
  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.
  - snazz 6y ago
    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.
  - aspenmayer 6y ago
    It sounds like a good idea to be implemented by a technical user, and a solution looking for a problem to every other kind of user. I thought dependency hell was bad but this sounds like a further circle of such hell. I like that I can tell a user to just update their browser and OS and be confident that most users will handle the operation thereof. I know how to tell a non-technical user how to update their web browser in words they can understand. I’m going to have to write a new script for how to explain the scope of the limitations of using a web browser as a compiled application versus the proposed modular architecture just so they can tell me they don’t want or need that. 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. https://beakerbrowser.com https://beakerbrowser.com
kryptiskt 6y ago
A browser lays out text and graphics (for any script in any locale), does GPU accelerated 3D rendering, handles network communication, plays video, plays audio, provides accessibility, parses a bunch of languages, compiles a couple of languages to machine code run in a security sandbox (and has a separate optimizing compiler), provides database storage, implements a plugin system, provides support for 25 years of legacy standards. And a bunch of more things.
- ken 6y ago
  It also reimplements all of those things itself from scratch because their priority is on cross-platform parity, not efficiency. Every time I see someone working on a FF bug I’m cc’d on, I marvel at how many files they have to touch to get anything done. One key binding missing, because they’re not using the system text field? Hundreds of lines of diffs, spread across a dozen source files.
vkou 6y ago
Having worked on codebases that are more than 10 million LOC, I'm surprised that Firefox's functionality fits into such a small amount of code.
aschatten 6y ago
Modern day browsers are essentially VM with rich customizable GUI.
- skohan 6y ago
  This is something I really deplore about the state of modern software development. Taken collectively, it's mind-boggling the amount of waste there is in terms of memory and CPU (i.e. energy) usage by running a huge portion of consumer software in the browser. We could achieve the same result so much cheaper, with better performance and UX, by putting a serious effort into a set of standards for handling code from an arbitrary source securely.
  - Epskampie 6y ago
    > a set of standards for handling code from an arbitrary source securely That is what html+js is. Why do you presume a different standard would be more efficient in the end?
    - skohan 6y ago
      HTML+ECMAScript keeps the developer at quite a distance from the hardware, and it imposes all kinds of limitations which don't have to exist. The web is good enough for pure content delivery, but for more advanced interactive applications, the limitations are a huge waste. For instance, I have a computer at home with a 12-core, 24-thread processor, but web applications are basically single-threaded with some very limited support for web workers. I'm also limited to basically one language, which is garbage collected, so performance and memory usage are significantly worse than they could be. And as far as graphics, you're limited to WebGL which is ages behind the state of the art in terms of graphics APIs. Basically there is a whole universe of tools out there for software development, but if you want to target web you're limited to a handful of poorly performing, hacky options. For my work, we use several web applications to collaborate. As someone who works on highly optimized user-facing software, it's frustrating to understand how poor these web applications perform given the potential of modern hardware. The reason we use them is because you can send anyone a link, and they're into the software in one click. There's no reason we couldn't have the same experience for native software, where when you click the link your computer downloads a native binary and runs it in a sandboxed environment against a standardized system API. It would take a lot of careful work and planning, but there's no technical reason it couldn't exist, and it would be so much better for developers and users.
oreally 6y ago
This LOC count is going to be a huge problem in the future, and you'll see it as the bug count climbs. It'll be hard for people to understand how the system works and hard for them to ramp up. You'll see the slow decline if there's ever a point in which their funding is reduced and employees have to be laid off.

djanogo 6y ago

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 if apps can't stfu and be at 0% while in background with simplest use case. I am going back to close app's when I am done using it.

mschuster91 6y ago
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 and the other parts of the graphic and input stack to achieve the (measurable!) performance advantage over other browsers. For me personally, this is uncompetitive behavior that should be punished, but oh well, anti-trust legislation isn't exactly something that got much use over the last decades :(
- paulryanrogers 6y ago
  Doesn't Safari also lag in implementing new or battery-hungry features? I suspect that could be a big factor too.
- _startingover 6y ago
  The rendering engine is open source. You’re welcome to audit it here: https://webkit.org/getting-the-code/ https://webkit.org/getting-the-code/
- spijdar 6y ago
  You think Apple should be punished for creating a vertically integrated stack? Setting aside private APIs as I have no idea what Safari does or doesn't use (although vast portions of it are open source, enough that you can compile modern versions of WebKit and "upgrade" the ancient WebKit on PowerPC Macs), another browser could be just as closely integrated as Safari. Obviously, the cost/benefit ratio is awful for Mozilla and Google, so they won't, but why should Apple cripple their own software? Safari's development costs, as part of MacOS, are funded by profits from Mac sales. Safari is deeply integrated with MacOS which is in turn deeply integrated with the Mac. In my opinion the whole point of the Mac is this vertical integration, and the main value-add of Apple's sphere. If you don't value that, there are cheaper options where cheaper and more flexible software is available. To me, an anti-trust suit would make sense for Safari on iOS, where Apple has locked all competitors out (in practice). Saying Apple should be fined for Safari because it's more integrated and efficient and that's not fair to Chrome and Firefox seems a bit silly, especially given (desktop) Safari's relatively small usage numbers. All IMO of course.

webmobdev 6y ago

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 versions they really cared about optimizing for performance, using less memory and less power (on mobile devices) - I am amazed that years after, modern browsers are bloatier now than ever and just don't seem to care as much about these aspect as much as Opera did. Questions like how modular is Firefox, how easy is it to customize Firefox (add or remove feature from the code), how easy is it for someone to use the Gecko rendering engine in their own project etc. all kind of indicate the bloatier, messier nature of the code within Firefox (in my opinion). It's like browser developers now a days only care about adding more features (read bloat) without considering any constraints ...

gsnedders 6y ago
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 who care about running on limited devices, of _course_ the company invested more in running well on them. And I wouldn't hold up Presto as a great example of modularity or the ability to embed the rendering engine in other projects.
- webmobdev 6y ago
  > 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) https://en.wikipedia.org/wiki/Presto_(browser_engine) (2): https://filehippo.com/download_opera/8.02/ https://filehippo.com/download_opera/8.02/ (3): https://stackoverflow.com/questions/29055475/qwebview-or-qwebengineview https://stackoverflow.com/questions/29055475/qwebview-or-qwe... (4): https://medium.com/@smsnobin77/firefox-build-macos-f1f53d643e81 https://medium.com/@smsnobin77/firefox-build-macos-f1f53d643...

alephnan 6y ago

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 definitely beyond the scope of design patterns undergraduate students are familiar with. By the end of the term, no one discovered a 0-day, unsurprising considering half the class didn't even try. There were 90 students in the class, and I ended up being the only person to produce a JS payload that would crash Firefox in one of the newer HTML5 libraries. It's neither a zero-day or exciting or profitable vulnerability though. Realizing everyone in the class would fail, the professor changed the grade of this project to only account for 30% of the grade. I spent most of my time on this project while disregarding the rest of the busy work for the class. In the end, I got a C grade while my peers who didn't even attempt to tackle this project received higher grades.

freeboson 6y ago
The syllabus where a grade is broken down by percentages is (at US institutions) considered to be like a contract. If the course originally had it at "70-80%", then it cannot be changed mid-semester without being acceptable to you. It's fairly incredible for this to happen (at a US institution).
totony 6y ago
Whenever you have trouble compiling something, just look at how gentoo approaches it. They're the last bastion making sure OSS is actually buildable. Them are their users most likely are the #1 source of build documentation, bug reports and fixes in OSS
vikramkr 6y ago
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?
- 6y ago

worker8 6y ago

bergheim 6y ago

I just wanted to say that, despite a few mishaps, firefox is what _everybody_ on hn should be using. I can give my browser-time credentials, but really. Firefox is amazing. Care for the open web, fear ie6, and at the same time enjoy firefox!

eitland 6y ago
> Care for the open web, fear ie6, and at the same time enjoy firefox! And remember: Chrome is the new IE. (Since a number of people have misunderstood this quote in the past I'll explain it up front: 1. IE was in some ways technically superior to competition until they became dominant. 2. At the same time devs stopped caring about other browsers, and then 3. Microsoft lost interest in it. We are repeating this it seems, currently at step 2 for a few years already, waiting for Chrome to completely outcompete other browsers and for Google to abondon it like so many other of their projects :-) Edit: I took the time to write down a slightly expanded version of the explanation above: https://erik.itland.no/chrome-is-the-new-internet-explorer-4-stages https://erik.itland.no/chrome-is-the-new-internet-explorer-4...
- deleted 6y ago
  [deleted]
- alephnan 6y ago
  For people who don't care about privacy, what would be the motivation for making the switch? Chrome is good enough. The interface is still streamlined. Microsoft didn't just lose interest in IE, but it became bloated with the toolbar. The UI wasn't well proportioned in general. Web development wise, it was a struggle to be compatible with IE. Chrome may be setting the web standard for better or worst, but atleast developers are more comfortable developing and testing Chrome. The sentiment is that writing code to work I.E. would be exceptional, whereas now writing code for non-Chrome browsers would be the exceptional case. In fact, developers sometimes only test Chrome. Some popular E2E JavaScript testing frameworks only work with Chrome. Also, I don’t know if there are examples of Chrome implementing non-standard behavior that rivals IE having an event bubbling system that was inverted from every other browser.