There is no point in launching a “web app store” just for the sake of countering Google’s move. The web is a pretty good way to distribute web apps already, and if there is going to be a new distribution mechanism, it should have clear advantages over the status quo. In the case of the Chrome Web Store, Google’s blog post cites a few concrete advantages: easier discovery of quality web apps, increased permissions for installed apps and a new business model for developers (specifically, selling apps directly to users).

Easier discovery is a no-brainer, but of course this could be accomplished by a simple web app directory that links directly to various apps on the web. There’s no need to “install” apps to achieve this. There has to be more to a web app store than this. In particular, I love the idea of charging (optionally) for apps. Developers need to eat, and plastering web pages with ads shouldn’t be the only way for them to monetize the fruits of their labor. At one point I thought long and hard about starting a business around a marketplace for Prism web app bundles.

So I agree broadly with Google’s vision for their web store. But we can do better. For one thing, we can be more open, as Jay suggests, rather than using the store to lock users into a specific browser. In addition, we can take advantage of Prism’s much more mature and technically sophisticated platform for adding value to web apps when they are installed locally. After all, Google is promising to deliver something “later this year” whereas Prism web apps like Zimbra Desktop are already being used by tens of thousands of users every day.

I’m proud of what we’ve achieved so far with Prism despite limited development resources. Now is the time to start experimenting with other ideas as web apps continue to meld with traditional desktop apps. How should web apps be discovered and delivered? What does it mean to “install” a web app locally? What new capabilities (and associated APIs) are needed for web apps to rival their desktop equivalents, beyond what is already offered by HTML5? How might a web app payment model function? I believe Prism would be a great vehicle for Mozilla to tease out and play with potential answers to these questions.

To be safe, I’ve completely removed any code that might lead to this type of problem. This should not affect the correct functioning of the protocol handler registration. Prism 1.0b4 is now live on the website. A few other bugs have been fixed as well:

512055 Prism Text Search goes backwards (Next/F3 goes up instead of down through the document)
550700 Hide on close for Mac
557108 Environment settings in override.ini are not used
557110 Command-M doesn’t minimize window of Mac
557112 Command-W causes app to close even if HIDE_ON_CLOSE is set
557519 Protocol handler doesn’t work when window is hidden (HIDE_ON_CLOSE)
559328 Clicks on external links aren’t detected in popup windows
559524 Clicks on non-anchor links don’t open in external browser

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