After Firefox 4, the Mozilla community decided that we needed to be more agile and ship Firefox faster. This “rapid release” process has been absolutely fanstastic for the Mozilla engineering/development community: we have been able to develop more quickly, and the process has made Firefox development a lot less stressful because there will always be another release in 6 weeks. But rapid release has its downsides, and I think we, as a community, should consider whether we are serving the needs of our users.

Much has been said about how the rapid release process is problematic for “enterprise” users, or other situations which use managed deployments and have unusual testing requirements. I know that we are discussing a plan to work with enterprises to provide a longer-term support system for these users.

But even for ordinary “consumer” users, there is still a significant pain point in the rapid release process. Not all extensions are keeping up with rapid release. Traditional Firefox addons are given almost infinite power to modify the application, but with this power comes a price: any change we make has the possibility of breaking an addon.

We are working on many projects to mitigate this problem. The Add-on SDK (Jetpack) gives addon authors a way to write addons against a stable API that we promise will be maintained across versions. And most of the time, even though an extension is actually compatible with a new version, we aren’t sure about this compatibility. We are planning on asking our Aurora/Beta testing audience to help us test addons to mark them compatible by default.

But even with all these mitigation strategies, there are still going to be users who have incompatible addons on each 6-week cycle, either because they are using unusual or custom addons, or because an addon which is critical to that user needs major update work which cannot be completed in a particular release cycle. Users are then given the unfortunate choice of updating Firefox and having important extensions broken, or not updating Firefox and potentially being exposed to security flaws.

We should continue the existing rapid release process: it makes our development practices better, and for a majority of users it gets them the newest and best web features and Firefox performance improvements as quickly as possible. But for users who have a long tail of addons which are updated less frequently, we should complement the rapid release vehicle with a stable release which will contain security fixes but won’t break extensions for a longer period of time. This could be a release vehicle which has updates only on a 6-12 month cadence.

This is definitely not an easy decision; maintaining a stable version will cause pain for our community. The development community will have to do security/stability backports against older code. Our testing community will somehow have to deal with an additional train of releases beyond the existing nightly, aurora, and beta release trains. We will have to deal with pressure to rush a feature into an stable release, or delay the schedule in order to pick up an important feature. Finally, a stable release will be a pain for extension authors themselves, because extensions must provide and maintain versions which are compatible with both the rapid and stable releases.

I fear that we are frustrating our users with extensions, which ought to be one of Firefox’s greatest strengths.

As Mozilla increasingly focused on being the best browser for mobile devices, we will need to focus on battery usage. This is already an issue on laptops, where some browser activities like playing movies can chew through battery very quickly, but it is even more an issue on smaller phone and tablet devices where batteries are smaller and users expect at least a full day of battery life.

The first part of this project will be accurately measuring our power usage under various conditions. As with any software engineering project, you are what you measure! To that end, Mozilla is looking for both volunteers and potential paid employees who are experienced at measuring and tuning power usage on small devices. If you have experience with software or hardware tools for measuring power usage (both is even better), please contact me at benjamin@smedbergs.us, or go ahead and apply for the job.

Mozilla is a great place to work, whether you are working out of one of our offices (Mountain View, San Francisco, Toronto, Paris, London, or Auckland) or working remotely. Especially with a new project such as this one there will be plenty of opportunities to chart your own course, and improve software which is shipped to millions of users.

The system is working. We found a crash bug soon after it was introduced, and saved Firefox users pain and aggravation.

Yesterday, dbaron was looking through data from crash-stats.mozilla.com and found a spike in crashes on nightly builds. Because this was a bug related to delivering stream data to plugins, an area that I rewrote for Firefox 4, dbaron cc’ed me as he filed bug 646839.

The bug immediately triggered alarm bells for me: all of the crash stacks were taking “unusual” paths having to do with multipart streams, or networking code that was being intercepted by JavaScript, probably from an extension. In addition, nothing had changed in the Mozilla code that looked remotely related to the crash. After some data mining, I discovered that the users who were crashing had a beta version of Adblock Plus installed. I immediately cc’ed Wladimir Palant, the ABP maintainer.

It turns out that a new feature in Adblock Plus was eating some error codes, leaving our plugin code in a bad state. This resulted in crashes. And the new version of Adblock Plus was schedule for release to Firefox release users soon! Because of dbaron’s quick discovery, a nightly user base who runs beta versions of extensions, and quick thinking all around, we were able to avert a problem for users of Firefox release builds.

This kind of success story is possible because of many tools and systems which interact, but it is mostly possible because Firefox development is an open community where everyone works together and we don’t hide our flaws. And that’s why I love working on Firefox.

Are you interested in becoming a volunteer contributor to Mozilla? See our contribution center for more information about how you can help with coding, QA, documentation, support, localization, marketing, or other efforts of the Mozilla community. Or do you have the skills and experience to be a Mozilla employee? Contact me, or visit the Mozilla careers site and apply today!

In Firefox 4, tab are “on top” by default. When you are in maximized mode, this also means that the tabs move up into the titlebar. I understand that the UI design team decided to do this to make the tabs easier to click (because of Fitts’ law), but I personally find this behavior annoying, because it means that you cannot use the title bar for its normal tasks. I almost always double-click the titlebar to switch between maximized and regular mode, or drag the window to the side to get half-screen mode.

Fortunately, there is a hidden preference which controls this behavior. You can restore normal title bar behavior in two ways:

• Set the hidden preference “browser.tabs.drawInTitlebar” to false, using about:config
• Install my extension Aero Window Title, which not only changes the default preference for you, but also puts the window title back onto the screen so that you can see the title of the current tab easily.

While I’m talking about it, I’d also like to plug my other new extension, Iconic Firefox Menu, which will turn the orange Firefox menu (on Windows) into a Firefox icon. Together, the two extensions look like this:

In order to support running Jetpack-style extensions in another process, Firefox 4 has support for running arbitrary JavaScript code in a separate process. Although this code was designed primarily to support the Jetpack SDK, Firefox and extensions can use this support to run arbitrary code in a separate process.

Running code in a separate process has advantages similar to running code in a separate thread. The running code will not block the main Firefox user interface. An added advantage is crash protection: if the code causes a crash, it will not take down the entire browser. There may also be some performance benefits from separating the garbage collection heaps and avoiding XPCOM overhead.

The basic steps to start a subprocess and run code in it are as follows:

var process = Components.classes["@mozilla.org/jetpack/service;1"].
  getService(Components.interfaces.nsIJetpackService).createJetpack();
process.evalScript("Put your JS here");
// When you are done with the process, you should explicitly destroy it.
process.destroy();

Of course, running a script in another process isn’t that useful unless you can communicate with it. This is accomplished by passing messages back and forth. To send a message to the remote process, use process.sendMessage:

process.sendMessage("messageName", param...)

To receive messages from the remote process, register a receiver function:

process.registerReceiver("messageName, function(messageName, argument...) { ... });

The remote process has access to a similar set of global functions, as well as the ability to create sandboxes and use ctypes. For more information about the full capabilities, see the Mozilla Developer Center documentation. Note that code running in a jetpack-style process does not have access to XPCOM, because XPCOM is not started in the jetpack process; it runs code using only the JavaScript engine.

If an extension is using ctypes to work with third-party code or OS libraries, I strongly encourage that extension to consider running the code in a separate process for crash protection. If an extension has long-running or computationally expensive tasks, it might make sense to move those into a separate process as well. If nothing else, it will make it much easier to measure the CPU and memory usage of that code separate from the rest of Firefox.

Bank of America is asking me to agree to a “Electronic Communications Disclosure” which includes the following text:

(5) Hardware and Software Requirements

While you may be able to access and retain the Communications using other hardware and software, your personal computer needs to support the following requirements:

For Online Banking:

• An operating system, such as:
  • Windows NT, 2000, ME, XP, Vista, or Win 7; or
  • Macintosh OS 10.x
• Access to the Internet and an Internet browser which supports HTML 4.0 and 128bit SSL encryption and Javascript, such as:
  • For PC using Windows NT, 2000, ME, XP, Vista, or Win 7
    • Microsoft Internet Explorer 7.0 and higher
    • Firefox 3 and higher
    • Chrome 3.0 and higher
  • For Macintosh using OS 10.x
    • Safari 3.0 and higher
    • Firefox 3 and higher
    • Chrome 4.0 and higher

For Merrill Lynch brokerage websites:

• You must have access to a personal computer with browser software such as Microsoft Internet Explorer; Adobe Acrobat Reader; and Internet access (at your cost).
  • Browser and reader versions necessary to view the Merrill Lynch brokerage websites are as follows:
    • Microsoft Internet Explorer version 6.0 and later
    • Firefox version 3.5 and later
    • Safari version 3.2 and later

Most Communications provided within Online Banking, Merrill Lynch brokerage websites or at other Bank of America websites are provided either in HTML and/or PDF format. For Communications provided in PDF format, Adobe Acrobat Reader 6.0 or later versions is required – A free copy of Adobe Acrobat Reader may be obtained from the Adobe website at www.adobe.com.
Download Adobe Reader for free. Link opens new window.

In certain circumstances, some Communications may be provided by e-mail. You are responsible for providing us with a valid e-mail address to accept delivery of Communications.

To print or download Communications you must have a printer connected to your computer or sufficient hard-drive space (approximately 1 MB) to store the Communications.

Does this entire section say anything other than “You have to have an operating system and a web browser, and sometimes a way to view PDF files, and here are some programs you can use.”? Why bother writing it at all?

Asa is wrong, and he’s being obnoxious about it to boot. What Google, and Apple, and Microsoft is doing is called software integration, and in general it’s very good that iTunes, Google Earth, and Windows Live are adding Firefox integration into their software. They are installing plugins and/or extensions using the recommended methods so that all NPAPI-capable browsers can see and load them. This is not “Google being bad”, this is Google following Mozilla’s recommendations for browser integration!

It’s true that Firefox should give users more control over integration software that is found on the system, and we’re working on prompting users whether they want to include that integration as part of Firefox. But claiming that Google, Apple, and Microsoft are somehow being evil is stupid and short-sighted. The problem, if there is one, lies entirely with Firefox, not with the software which is doing exactly what we ask of them.

Firefox 4 implements a new strategy for painting windowless plugins. This should result in improved performance and responsiveness when users are visiting sites such as Hulu and Vimeo which make use of windowless Flash to render their videos.

Background

On Windows and Linux, there are two basic modes in which plugins can render, windowless and windowed. When a windowed plugin instance is requested, Firefox creates a native widget; the operating system delivers native events, including paint requests, directly to the plugin window. This is simple, but it has a significant disadvantage: the plugin doesn’t participate in normal web layout. This means that the plugin cannot be transparent, and CSS effects such as opacity and most transformations cannot be applied to the plugin. Youtube currently mostly uses windowed plugin instances for rendering their videos.

Windowless plugin, on the other hand, do not have a native widget. Instead, events such as mouse and keyboard events, as well as requests to paint the plugin, are received by the browser and forwarded to the plugin using the NPP_HandleEvent API. Hulu and vimeo both make use of windowless plugin instances. Any Flash plugin with the wmode=”opaque” or wmode=”transparent” attribute in their <embed> or <object> tags is using windowless mode.

Asynchronous Painting

In Firefox 3.6 and earlier, every time the operating system asks the browser to paint its window, we synchronously walk the layout frames and ask each frame to paint itself. When a windowless plugin frame is asked to paint, it synthesizes a WM_PAINT event and sends it to the plugin using NPP_HandleEvent. This is straightforward, but it does involve a blocking call and process round-trip for plugins which run in a separate process.

In Firefox 4, we don’t paint the plugin directly to the screen. Instead, as soon as the plugin is visible we ask it to paint to a retained buffer (an X surface on Linux, and a shared-memory DIBSection on Windows). We retain the pixel data for the next time Firefox is asked to paint. When using D3D rendering, we can eagerly upload the plugin data to a texture, and the plugin texture is composited by the graphics card and GPU.

A Behavior Change: Opacity on Windows

On Windows, the new asynchronous painting API has one significant side effect: plugins responding to a WM_PAINT message must be aware of opacity. The device context which is passed to the plugin is backed by a DIBSection with an opacity channel. Certain Windows Drawing functions, such as the DrawText function, are not aware of opacity and will incorrectly overwrite the opacity data, leaving black splotches where transparent text was intended. Windows drawing functions such as AlphaBlend are the correct way to draw while preserving transparency information.

Most Flash and Silverlight sites work correctly with this new function, but there are a few Flash features which continue to use the old Windows APIs. This bug shows itself in current Firefox nightly builds as black splotches where text should be painted, and is being tracked by Mozilla bug 611698; we are working with Adobe to resolve this issue before Firefox 4 is released.

Testing Wanted

Although our implementation of asynchronous painting passes all of our internal tests and appears to work well in general, the web is a big place and we can’t test every page or plugin available on the web. We would really like people who develop with plugins or use plugin-intensive sites to test Firefox nightly builds and report any bugs which you see! These builds are updated to our most recent Firefox each night, so you will always have the latest and greatest features (and sometimes bugs) to experiment with.

Note to Flash Authors

If your site uses wmode=”transparent” but your Flash application is not actually transparent or translucent, you can get better performance in both Firefox and Chrome by switching to wmode=”opaque”. Please use wmode=”opaque” for content which does not need actual transparent behavior.

Since crash bugs are a top priority within Adobe, there is one relatively simple step Adobe should take which would make it much easier for everyone else to help Adobe track and diagnose crashes: implement a symbol server.

A symbol server is a public web server from which developers can fetch debugging information (PDB files) for released binaries. The Microsoft debuggers have excellent support for automatically pulling down symbols as they are needed in the debugger. Mozilla runs a symbol server for Firefox nightlies and releases, which is invaluable for people debugging and profiling Firefox without having to do a custom build. Microsoft runs a symbol server which contains debug information for Windows and many other Microsoft products, including the Silverlight plugin.

Debug information is not simply a way to get symbolic information from Flash. It is necessary in order to get any useful stack trace of the Mozilla code which is calling Flash. A common compiler optimization called frame pointer omission (FPO) avoids storing the frame pointer in the x86 EBP register, freeing that register up for general use. In order to walk the stack of this optimized code, the debugger has to query the frame size and frame pointer information from the PDB file. When debug information is not available, stack walking doesn’t produce usable results.

As an example, take the current #3 topcrash for nightly builds of Firefox (mozilla-central). The signature for this crash is NPSWF32.dll@0x1e7fe4. The stack traces from Mozilla’s crash reporting system are completely opaque:

Even worse, the crash signature depends on the particular version of Flash that is installed on the user’s computer. We can’t tell if a particular crash signature is fixed by a new revision of flash because without symbols we can’t correlate crashes between different versions.

As part of developing multi-process plugins for Firefox, we are constantly dealing with unexpected plugin behaviors. Whenever we encounter a problem which can be reproduced in both Silverlight and Flash, we’ll always test with silverlight, simply because Microsoft makes Silverlight symbols available through their symbol server and therefore we can actually step through their code and ours in a debugger.

Adobe should set up a symbol server for their three main plugins, Flash, Shockwave, and Acrobat. By implementing this simple tool, Adobe could help all browser vendors and interested hackers to help identify and fix bugs. If Adobe is concerned about using full debug information to reverse-engineer details of their code, there is a way to strip the PDB files so that only frame-pointer information and function names.

Out-of-process plugins (OOPP) are now on by default in mozilla-central! Starting tomorrow morning, the mozilla-central nightly builds will load Flash and all other plugins in a separate process by default (on Windows and Linux). The Electrolysis team would love for people to test any plugins on their system, especially less-popular plugins.

Since we are moving relatively quickly with multi-process plugins, there are a few known issues to be aware of:

• The plugin-crash UI is not finished. The current UI is just a non-localized dialog so that we can get crash reports from nightly testers. This will be changed soon!
• On Windows, tearing/repainting issues when scrolling, bug 535295
• On Linux, compiz effects and Flash don’t work together on some systems, bug 535612
• On Windows, selecting “Print” option in Flash may lock up Firefox, bug 538918
• On Windows, hulu won’t switch to full-screen mode, bug 539658
• On Linux with GTK+-2.18 or later, GDK assertions and a fatal XError, bug 540197
• Firefox-process crashes at NPObjWrapper_NewResolve with silverlight and sometimes Flash, bug 542263

If you discover crashes while running nightlies, please make sure you submit them, and check about:crashes for the crash ID and signature. We could use help making sure plugin-related crashes and instability are filed and tracked by searching for signatures here and filing bugs in the Core:Plug-Ins component.

If your browser hangs, you can probably recover by killing the mozilla-runtime process in the Windows task manager or via `kill` on Linux. If you are a developer with a debugger, please use the Mozilla symbol server and get stacks for both the Firefox process and the mozilla-runtime process and file a bug.

In some cases, it may be useful to the Electrolysis developers if you obtain a plugin log, which is a log of calls made between the plugin and the browser. Instructions for obtaining the log are available here.

I am very excited that we’ve made it this far, and I look forward to our next milestone release, which will backport these changes to the 1.9.2 release in preparation for Firefox Lorentz.

If for some reason you need to disable multi-process plugins, set the pref dom.ipc.plugins.enabled to false.