A response to “How Google is quietly killing Firefox”

Here is a response to this article

Article summary

The article explains that browsers (all including Firefox and Chrome according to the author) crash more frequently because of a lack of memory since web applications are now more JavaScript intensive. The author explains that it’s not always the browser’s fault to be memory hungry and sometimes is the fault of the web developer. I agree with this part. I would even also add that it is not because JavaScript has a garbage collector that it avoids memory leaks. Some leaks are at the application level and I really think a “WebValgrind” should emerge to tell at the JavaScript level where a web app leaks.

Then starts paranoia:

Mozilla’s greatest revenue source today (accounting for more than 80 percent of annual income) is Google. Mozilla is deeply dependent on Google for operating revenue.

Mozilla is not dependent on Google. Mozilla is dependent on search-related contracts. Asa Doltzer wrote about it 4 years ago. He was right at the time and what he wrote still stands. Mozilla is not dependent on Google.

And it goes on:

If you buy the theory that most people who abandon Firefox do so because it crashes (runs out of memory) unpredictably, it stands to reason that all Google has to do to pick up market share in the browser world is publish AJAX-intensive web pages (Google Search, Gmail, Google Maps, etc.) of a kind that Firefox’s garbage-collection algorithms choke on — and in the meantime, improve Chrome’s own GC algorithms to better handle just those sorts of pages.

Response on different points

Google creates AJAX-intensive web apps that purposefully leak

This is a ridiculous accusation. Imagining that all competitors started to have better garbage collection, what would they be left with?

Google makes AJAX-intensive applications for the purpose of improving the user experience. End of story. Memory leaks are the result of the current software attitude which is to keep adding features without caring long-term performance.

Memory leaks are made to make Firefox crash

This is ridiculous as well. Does anyone really think that Google web devs wake up in the morning thinking “hey, what about I add a few more memory leaks to make a some browser crash?”. If the browser crash with a given service (Google maps, for instance), some people will change of browser, some others will just change of service and this is not in Google interest.

Also, why does Firefox crash in the first place? Maybe Firefox should work toward improving it’s memory management? Oh wait! they are already working on that!! (and these are just a few links). Once we see improvements of these bugs on Firefox, I guess Google web devs will have to work a lot harder to make Firefox crash. Good luck, guys!

On “Google is a uniform corporation with an evil plan to kill Firefox, booo!”

I recently attended JSConf.eu and I’ve had the occasion to chat a few minutes with Erik Corry after his talk on improving V8 garbage collection. Call me naive or stupid, but the image I kept from him was the one of a dedicated (maybe even passionate) engineer working to improve his product. Is he a slave serving an evil Masterplan to control the universe? I don’t think so.

On hyperbolic blog article titles

How Google is quietly killing Firefox“, “Is Google Chrome the New IE6?“… What is the next title? “Chrome is bringing back Nazis”?

Chris Heilmann already warned us about hyperboles (start at slide 74). I think we really should stop these titles, because they create more confusion that anything. No, Chrome’s plan is not to kill Firefox by purposefully introducing memory leaks in its webapps. No, Chrome is not IE6. There are many differences.

I agree that there are some disturbing informations about Google and its commitment to openness, but it does not make Chrome IE6.

Side note. It took me some time to understand why my previous post hit 1400 views and I get now that it probably its title was sort of flashy. I regret it.


7 thoughts on “A response to “How Google is quietly killing Firefox”

  1. One interesting aside: in the Gecko engine (in Firefox) we mandate Out-Of-Memory checks in our coding guidelines (checking the return value of the memory allocator) — we have to appropriately handle any place that the memory allocator could say, “sorry, I don’t have enough memory to satisfy that request!” From what I’ve read of code in other engines, this guideline either doesn’t exist or is not followed so stringently, so we probably do a better job at handling OOM in a good number of instances with pathological memory behavior where other engines would just crash with a NULL pointer dereference.

    • How do you ‘appropriately handle’ a memory allocation failure?

      I think we (V8) catch all the places where an allocation fails. The one expection is a failure to autogrow the stack, but I never saw any big program in any language that handled that. (We check for stack overflow, but if the OS fails to autogrow the stack before we hit our stack limit we are busted.) But once we caught a failed allocation you still get a sad tab. What else can you really do?

      You can throw an exception, but that doesn’t really solve the problem. The VM is still out of memory and whatever it tries to do next will probably cause another OOM.

      You can try to do a GC, but since you are so close to the limit, the VM probably already did 10 back-to-back GCs in an attempt to get memory. All that happens is that the browser freezes, while it does endless GCs. And if the OS is really refusing you more memory you can only do mark-sweep GC, there’s nowhere to move the data to for a compaction (we don’t have in-place compaction any more).

      You could disable JS, but then the user probably has no way to save their work, and it doesn’t prevent the browser from trying to allocate memory.

      If a malign/buggy page was using up all the memory you really want to kill it so you can get your memory back.

      • Hey Erik! Thanks for the response. I was basing my information on some recent code reading that I did, but I’ll look into it a bit more and make a blog post to clarify and/or correct my comment — I’ll give you a ping on Twitter when I post that, have to get a few other things off my plate first!

  2. Hmm, I haven’t noticed /that/ much paranoia in Kas’ blogpost. Kas explains in a human-readable way that most memory leaks are more and more related to web apps, and that there is a possible conflict of interest regarding Google web app leaks in Firefox.

    Yes, Kas might get a bit paranoid on the last paragraphs but I still think the context is worrying: there are more and more websites / webapps that are designed to work better (if not /only/) on Chrome — this is what most of the “Is Google Chrome the New IE6” blogpost is about, btw.

    However, you’re sure right that both titles are vastly exaggerated, or even misleading. You’ll notice I chose another title to tweet about Kas’ blogpost. 😉

    • “I still think the context is worrying: there are more and more websites / webapps that are designed to work better (if not /only/) on Chrome — this is what most of the “Is Google Chrome the New IE6” blogpost is about, btw.”
      => I could not agree more and I always feel weird when I go to /chrome/.angrybirds.com. It just feels wrong. Especially since it works fine on Firefox!
      The proliferation of websites which are made to work on one particular browser is really worrisome. It’s like no one learned the lesson. Eventually, it may lead to websites using too much these technologies and competitors having to implement the technologies as they are (bugs and bad APIs included).

      “You’ll notice I chose another title to tweet about Kas’ blogpost. ;-)”
      => I did notice 😉

  3. This is the perfect website for anybody who would like to understand this topic.
    You understand a whole lot its almost tough to argue with you
    (not that I really will need to…HaHa). You definitely put a new spin on a topic which has
    been discussed for many years. Wonderful stuff, just wonderful!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s