New Gecko OS X Widgets Module Owner: Steven Michaud

I’ve been Gecko’s OS X (Cocoa) Widgets module owner for a long time. The code in this module is Gecko’s OS X compatibility layer.  Today I’m handing over the reigns to Steven Michaud.

We’re fortunate to have such a capable and active new owner. Steven has been working on this code with me since before Firefox started using it by default in 2006, and in more recent years he’s been doing the bulk of the maintenance work. In addition to knowing the module well, he’s got great debugging skills. Those skills are joined by some serious perseverance, which means he can get to the bottom of just about any bug.

Thank you, Steven!

Posted in Mozilla | 1 Comment

Informal Test: Building Firefox with VMWare vs. VirtualBox

I needed to set up a Linux virtual machine on a Windows host for working with Firefox OS. I don’t like working in slow VMs, so I did an informal test of VMWare vs. VirtualBox. I prefer to use open-source software when I can, so if VirtualBox is as fast as VMWare, or close, then I’ll just use VirtualBox.

Mozilla developers often work with VMs, and minimizing build times is a frequent topic of discussion, so I thought I’d post my results in case anyone finds them useful. If you have anything to add on the subject, please do so in the comments.

Host Software and Hardware:

  • Windows 7 Professional 64-bit, all updates applied as of Sept 12, 2013
  • Intel Core i7-3930K CPU @ 3.2 GHz, 6 cores
  • 16gb RAM

Guest Software:

  • Ubuntu 13.04 64-bit, fully updated as of Sept 12, 2013
  • Approximately the minimum number of packages installed in order to build Firefox

VirtualBox Config:

  • VirtualBox 4.2.18
  • 4 CPUs (VirtualBox does not have CPU vs. core distinction that VMWare does)
  • 6002mb RAM assigned to VM

VMWare Config:

  • VMWare Workstation 10, purchased
  • 2 CPUs with 2 cores each, for a total of 4 cores
  • 6004mb RAM assigned to VM

The test was was to create a Firefox nightly debug build (latest code as of Sept 12, 2013) with the command “time make -f client.mk”, using the “-j4″ flag for make.

VirtualBox Build Time

  • real: 28m53.005s
  • user: 88m32.932s
  • sys: 10m6.376s

VMWare Build Time

  • real: 29m31.595s
  • user: 89m22.548s
  • sys: 11m6.192s

Given these results, I’m just going to use VirtualBox. I’ll note, however, that graphics performance (and subsequently, UI responsiveness) in VMWare does seem to be noticeably better than VirtualBox. I don’t care, but if you do, VMWare’s advantage here is fairly noticeable even in simple interactions. VirtualBox is not bad though. Also, I didn’t test device support or too many different VM configs for the sake of tweaking performance. Take my results as a rough guide at best.

I did test VirtualBox with fewer CPUs, to test a rumor I’ve heard in the past that adding CPUs to a VM doesn’t improve performance much, or could even hurt it. That rumor seems to not be true, or is no longer true, at least with VirtualBox and my setup. Build times went from 101m, to 52m, to 28m, for 1, 2, and 4 CPUs, respectively.

Posted in Mozilla, Programming | 3 Comments

Exciting Stuff: Firefox 19′s Built-in PDF Viewer

Firefox 19′s built-in PDF viewer is pretty exciting — not just because Firefox (finally!) has a PDF viewer, but because it’s written in JavaScript. Why is that exciting?

First, we’re always looking to extend the web platform’s capabilities. Writing a PDF rendering engine in JavaScript pushed the platform’s boundaries. We learned quite a bit while working on our PDF viewer, and we used that information to improve Firefox and the web platform in general [1].

Second, being written in JavaScript is great for security. The alternative, pursued by all other browsers with built-in PDF viewers, is to include another binary rendering engine alongside the HTML and JavaScript engines. Adding hundreds of thousands of lines of C and C++ code to render PDFs is not a good thing for security. Complex binary engines are hard to secure, and PDF engines are no exception — ask Adobe or FoxIt. Mozilla’s built-in PDF viewer will not be without vulnerabilities, but they will be vulnerabilities in the web platform that we’re already committed to securing — we’re not adding to the problem.

There’s still work that needs to be done, but Firefox and the Web took a big step today!

[1] e.g. improved font handling, canvas APIs, and JavaScript performance.

Posted in Mozilla | 15 Comments

Mozilla Joining ISOC in Support of IETF Activities

Mozilla has been significantly increasing its participation in IETF working groups over the past couple of years. This has coincided with increasing investments in the networking layers of our software and the Web platform. Today we’re heavily involved in IETF working groups relating to key Internet technologies such as TLS, HTTP and HTTP/2, RTCWeb, WebSockets, and others.

We think it’s important to support the standards groups in which we participate, so I’m pleased to announce that Mozilla has become an ISOC (Internet Society) Silver member. Among other things, ISOC provides administrative and organizational support to the IETF. We believe supporting ISOC and, by extension, the IETF, is a solid investment in terms of our mission to promote openness, innovation and opportunity on the Web.

Posted in Mozilla | 2 Comments

Mozilla Removing Support for the ‘java’ and ‘Packages’ DOM Objects

We have removed direct access to Java from the DOM in Gecko. Specifically, we have removed support for the ‘java’ and ‘Packages’ DOM objects. These are not part of any web standards and we don’t believe they are good for the web.

Script can still interact with Java plugin instances via NPRuntime, authors simply have to instantiate a Java plugin instance to script against.

This change will be in Firefox 15. See Mozilla bug 748343 for more information.

Posted in Mozilla | Leave a comment

IETF 83 (Paris), HTTP/2.0, and Encryption

I attended IETF 83 in Paris this past week with my fellow Mozilla networking team member Patrick McManus. This was my first IETF meeting, and it won’t be my last given how productive and enjoyable it was.

Our primary goal was to participate in the HTTP(bis) working group, where we hope to standardize SPDY, possibly under the label HTTP/2.0. I learned quite a bit about how the IETF standards processes work and greatly enjoyed spending time with many of the people involved.

We’re excited about what SPDY has to offer in terms of security and performance. The HTTP/2.0 proposals based on alternatives to SPDY (or that deviated significantly) were interesting, but I’m still convinced that the solution we end up with should be based largely on SPDY. I can hardly imagine a proposal that better exemplifies “rough consensus and running code,” with plenty of data confirming its benefits.

I’m also more convinced than ever that encryption (e.g. TLS) should be a requirement in HTTP/2.0. This is the right thing to do for our users and there is now plenty of data available to debunk myths about unacceptable deployment costs. Mozilla has a strong history of standing up for user security and privacy and hopefully we’ll continue with that tradition by strongly opposing any solution that does not require encryption. Perhaps we should go so far as to decline to implement any non-encrypted solution that might be specified.

Posted in Mozilla | 9 Comments

Mozilla’s Networking Team in 2011

Mozilla created a networking team as part of the platform engineering group in April of 2011. There are nine of us now, spread out around the world, with me managing. We’re responsible for Gecko’s networking stack, including network protocol support, security, and caching. I want to share some of the things we did in 2011.

We landed a SPDY implementation for the upcoming Firefox 11. SPDY will remain pref’d off until we’ve completed testing and various reviews, but it works quite well already. We’re working with Google to properly standardize SPDY.

We added support for the latest WebSockets specification. Firefox 11 currently has WebSockets enabled in standard form, without our vendor prefix.

Firefox 11 also includes SSL performance improvements. We can now negotiate SSL connections in parallel, on multiple threads, instead of serially on a single SSL thread.

We’re looking forward to increased IPv6 usage and we want to make sure that Gecko handles it well. In the past year we’ve improved IPv6 auto-detection, proxy support, and security. These fixes are spread out among a number of Firefox releases.

We made a number of improvements to HTTP pipelining in 2011, largely related to batching and ordering requests efficiently. HTTP pipelining is interesting because it’s an improvement to an existing, widely-used technology, but it has compatibility issues. Pipelining is currently only in use for our mobile products, where the risk/reward ratio is clearly in its favor, but we may enable it for desktop products next year.

Performance on Android is a priority for us. One optimization for Android that we’re particularly happy with is a major DNS performance improvement, which is detailed in a previous post. We also did the work necessary to enable our disk cache on Android.

Networking performance can be hard to test due to the variety of network conditions users can be operating under. In order to add flexibility to our testing capabilities we developed a system called NeckoNet. NeckoNet is a software suite including, among other things, a web server (Apache), talos, and a modified netem kernel module. We provide a Linux VM with all of this properly set up. Using NeckoNet, we can adjust bandwidth, packet loss and latency for network tests.

We’ve also made many other bug fixes and optimizations, conducted security reviews, and spent time planning future work.

In case you want to follow our work in the future, I’ll point out some of the ways in which we communicate (in addition to B.M.O.). Mozilla’s main networking wiki page has links to a number of pages we use to stay organized, including quarterly goals. Starting in January 2012 our team meetings will be open, with dial-in information posted on the mozilla.dev.planning newsgroup the day before the meeting. These meetings happen at 10am Pacific every other Tuesday. We’re also going to try to blog about what we’re doing more often. Any blog posts will be syndicated to Planet Mozilla.

Posted in Mozilla | 5 Comments