The good news is that there is a workaround that Mac users can use while waiting for a fixed version of Firefox 3.6. Just download the file dependentlibs.list and place it in your /Applications/Firefox.app/Contents/MacOS folder (or equivalent if you don’t have Firefox installed in the default location).

Download the standalone version or Firefox extension.

I’m very pleased to say that (for whatever reason) I was able to reproduce the infamous Ubuntu crash experienced by some users of Prism 1.0b2. Some research led me to a bug in Bugzilla concerning a similar crash. I applied the patch from the bug to my tree, and the problem now appears to be fixed.

I’m not sure what the deal is with the extension. It wasn’t working before because Firefox on Linux is based on XULRunner and didn’t support the -app command-line option properly. I understand that has been fixed, but I’m not sure whether the fixed version of Firefox is now available to users. If someone could clarify that would be great.

The new builds are in the same place as the old ones:

Download Prism Standalone Version for Mac or Windows

Download Prism for Firefox extension for Mac or Windows

Download Prism Standalone Version for Mac or Windows

Download Prism for Firefox extension for Mac or Windows

The following bugs have been fixed:

494133 Set As Desktop Background not available when Prism extension is installed
506886 Check override.ini for environment variables if not found in application.ini
508019 Update version numbers for 1.0b2
508575 Click handler is not attached when login manager is disabled
509021 Make notification API more flexible by allowing optional arguments and an onclick handler
509294 Prism fails when web app URI does not have a base domain
517892 Provide platform glue with access to the associated window object
527260 Patch to add restore minimized window functionality to JS-API
527827 Build fails because prism/Makefile is missing in makefiles.sh
528903 Stub reports missing Microsoft CRT DLL
535194 Crash on Mac when registering unknown protocol handler
535197 Enable maximize on first run

However, that probably isn’t all there is to it. Many (most?) extensions include some kind of overlay that modifies the main browser chrome window. This file is called browser.xul in Firefox, but webrunner.xul in Prism. So you’ll also need to go into the chrome.manifest file in the extension XPI and change the overlay line. Say it reads:

overlay chrome://browser/content/browser.xul  chrome://extension/content/overlay.xul

You’ll want to change that to:

overlay chrome://browser/content/webrunner.xul  chrome://extension/content/overlay.xul

I sound like a ginsu knife salesman, I know, but that’s still not all. If the overlay modifies, say, the browser’s popup menu, in Firefox it would want to modify a <popup> with the ID “contentAreaPopupMenu” whereas in Prism it’s a <menupopup> with the ID “popup_content”. I don’t have a good explanation for why the IDs differ. I can only say that this decision predates my involvement in the Prism project. You can compare and contrast the IDs used for various browser chrome elements by looking at the code for browser.xul and webrunner.xul.

This should be enough for the brave of heart to hack a lot of Firefox extensions to work in Prism. But it’s hardly ideal. There are a few ways I can imagine to improve the situation:

• Harmonize the IDs of chrome elements shared by Prism and Firefox. At least this would make a lot of existing overlays work in Prism without modification.
• Rename webbrowser.xul to browser.xul. This would remove the need to modify the extension’s chrome.manifest in most cases.
• Implement an intermediate browser layer that can be used by Firefox, Prism and other XULRunner-based browsers. Right now, a lot of browser code in the Mozilla tree is under the toolkit/ directory and can be used by any XULRunner app (e.g. the download manager, extension manager, etc.). But some code is in the browser/ directory, which is part of Firefox, not XULRunner. It might make sense to factor out the code in browser/ that would be useful for other web browsers. Among other things, this would probably mean splitting browser.xul into two files, one used by Firefox and the other in the shared layer. Firefox extensions would mainly hook into the shared layer so they would work without modification in other XULRunner-based browser apps.
• Base Prism on Firefox. This is an idea that we discussed ages ago but somehow fell by the wayside. In a nutshell, Prism would be Firefox, but with most of the chrome hidden (e.g. toolbars). This would mean that pretty much any Firefox extension would work out-of-the-box in Prism. It would also solve many other Prism issues (e.g. people are always complaining that Prism lacks some feature — like Quick Find — that then has to be added to webrunner.xul by hand). The biggest challenge would be to hide the requisite browser chrome. I’ve yet to determine to what extent this might pose problems, but Daniel Glazman’s FullerScreen might provide some useful hints.

The idea of an intermediate layer is appealing from a software engineering standpoint, but doesn’t strike me as particularly realistic because of the changes it would require in Firefox code. I’m leaning towards basing Prism on Firefox (as we originally planned to do months ago).

Okay, maybe not. But you will surely win the gratitude of scores of Ubuntu Prism fans.

I gave a talk about why Prism is strategic for Mozilla (download slides).

(As an aside, this is the first time I’ve ever written down a script for a talk. Usually I just run through the slides a couple of times to practice and then wing it on stage. I found it very helpful to write down the text and practice it verbatim, although I didn’t actually read it during the talk. One big bonus is that people who didn’t attend the talk will be able to follow it by reading the slide notes.)