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

The situation is hardly likely to improve now that there are four major players in the browser space (Microsoft, Mozilla, Apple and Google). Bits and pieces of HTML 5 are starting to appear in production browsers, but the process has anything but speedy. The WHAT WG was set up in 2004, after all.

Is the future of the web doomed to be a tortuous succession of committee-driven specs that take years to achieve consensus and even longer to be implemented by vendors? Unfortunately, the answer is, to a large degree, likely to be yes. Thankfully there is an alternative path for innovation on the web, in the form of out-of-band browser technology such as plugins, Java applets and, yes, even ActiveX. XMLHttpRequest, after all, was originally an ActiveX component, and it has given new life to the web application space with the advent of Ajax. We may lament the proprietary nature of Adobe Flash, but would we be even this far is the development of a standard <video> tag (finally starting to make its way into the latest generation of browsers) if it weren’t for the phenomenal success of Flash video?

Which brings us to Chrome Frame. Google’s IE plugin has stirred up considerable controversy, including a predictable attack from the spin doctors at Microsoft. Recently, Mozilla top brass like Mitchell Baker and Mike Shaver have expressed their own reservations. In a blog post, Mitchell speculates that Chrome Frame may degrade the user’s browsing experience:

Once your browser has fragmented into multiple rendering engines, it’s very hard to manage information across websites. Some information will be managable from the browser you use and some information from Chrome Frame. If the Smart Location Bar in the “browser” doesn’t show the sites you’re trying to return to, then you need to find a way to open Chrome Frame and search there. Your “browser” can no longer aggregate information for you across websites. This defeats one of the most important ways in which a browser can help people manage their experience.

Shaver voices similar objections:

Running Chrome Frame within IE makes many of the browser application’s features non-functional, or less effective. These include private browsing mode or their other security controls, features like accelerators or add-ons that operate on the content area, or even accessibility support.

I spent some time playing with Chrome Frame, and it seems to me that Mitchell’s thesis does not jibe with the reality of how the plugin works. By replacing the content portion of the browser, Chrome Frame swaps out IE’s renderer with a faster, more standards-compliant alternative. But it doesn’t change any of the overarching browser user interface (the “chrome”, if you will). Bookmarks are still unified in a single place. The Smart Location Bar still draws from a single browser history database. As far as I can see, private browsing functions as expected. The limited facilities for “aggregation” provided by Internet Explorer, in other words, still work just fine.

Shaver’s concerns have more merit. Behavior inside the content page is likely to differ depending on the rendering engine used. I verified that this is the case with form autofill. Fields that were previously filled out in IE mode do not yield the expected suggestions inside Chrome Frame. I imagine that ongoing development may enable the Google developers to rectify some of these shortcomings (e.g. by using Microsoft’s APIs to tap into their database of form values and suggest form field values accordingly). But there is no denying that running a browser-in-a-browser entails some real drawbacks.

On the other hand, we have to weigh these against the potential advantages. Shaver contends that “If [users] want to keep using IE for sites that the site’s developers agree work better with Chrome — and we agree that the majority of sites are much better with a more modern browser than Internet Explorer — it is likely because of application behaviour.” I wasn’t able to find any hard data on this, but the anecdotal evidence I’ve heard paints a different picture. People don’t use IE because they are in love with the application’s functionality. They use it because their company requires it, some of their applications (especially intranet sites) rely on it or, most likely in my opinion, they simply don’t know any better. After all, only a tiny minority of normal folks can even explain what a web browser is.

Faced with a significant proportion of web users who have displayed a total unwillingness to migrate away from the archaic, broken browser that is IE6, Google had a few options. They could give up on using whizzy new browser features to develop new products like Wave. They could leave IE6 users out in the cold (and thus jeopardize the success of a product like Wave that depends on adoption by an entire group of collaborators). Or they could accept a slower pace of development due to the significant resources needed to get Wave to run in IE6. Seen in this light, the release of Chrome Frame is a brilliant and elegant move. There’s a decent chance that the same users that appear to see changing browsers as a scary or unfeasible proposition will be willing to install a new browser plugin.

Chrome Frame is not a perfect solution. But realistically it may be the best way for Google to continue to push forward innovation in the web application space without excluding the 25% or so of web surfers still using IE6 (and to some degree the even larger number using later IE versions). This is a huge whopping win, and small, potentially fixable inconsistencies in the way users’ form fields are autofilled pale in comparison.

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

I’m traveling right now, and my Linux setup is having some issues that prevent me from using it remotely. So for now I’m only posting builds for Mac and Windows. If someone Linux-savvy wants to volunteer to give me some quick technical support on IRC, that would help me to get the Linux build up as well. (Or if someone else wants to build it, I can explain how to do so.)

Download Prism: Mac or Windows

Download Prism for Firefox: Mac or Windows

Perhaps even more impressive is how effortlessly Chrome has carved out a recognizable niche for itself in a crowded, mature market with strong incumbents. All of its proponents that I’ve spoken to praise its small footprint (both in terms of screen real estate and system resources) and speed. Some may not agree that the browser should strive to be as minimalistic as possible, but it’s a defensible idea (and very smart positioning).

And now Google has taken the logical next step, announcing the Chrome Operating System. From their blog post this sounds like the minimum required to tie Linux (universally accepted as the open source kernel of choice) to the browser. The goal is to “re-think what operating systems should be”, adapting them to a new era where apps will run on the web exclusively.

This leaves Mozilla as the only major browser vendor which doesn’t have an operating system. Does it need to address the threat by coming out with an OS of its own?

One counterargument is well expressed by Mozilla CEO John Lilly:

Google, when they launched Chrome, the name Chrome was an ironic title. It implied they wanted to build a browser that didn’t have any chrome, that didn’t have any user interface – they just want to be a pane of glass to the Internet. Setting aside for a minute whether that is even possible, we think the technical term for a browser is a user agent. We think the browser can do much on behalf of users – it can help you find stuff, it can help you figure out what you want – but it can also mediate between what’s on your desk and what on the Web. It can meld those two together, mash them up so to speak. I think the browser sits at the interesting interface of client and cloud and there will always be that interface.

I brought up another in relation to Google Docs and other web-based software:

So now I know why Google Docs hasn’t encroached more significantly on Microsoft’s turf: it kind of sucks. Don’t get me wrong, I don’t need or want the zillions of bizarre features that traditional shrink-wrapped vendors insist of pushing on users in order to drive revenue from useless “upgrades”. But something as basic as table management should just work, and the exported output should look like the original document, dammit.

Despite Arrington’s assertion (in the above-linked post) that “you won’t miss Office” thanks to web-based alternatives, the opposite is true at present. I talk to people constantly who won’t even switch to Mac Office because it isn’t compatible enough with the Windows version.

That said, I believe that the shift of software to the web is an inexorable trend. Google recognizes this, and they are tailoring their strategy to the world five to ten years out. This is sensible since it will take that long to put together a viable alternative to mature operating systems like Windows and OS X. By extension, Mozilla may find itself in an untenable position in this timeframe. If Google is successful with its strategy (which in practice means OEM deals that will see its OS and browser shipped pre-installed on new computers), Firefox will be the only major browser that has to be explicitly downloaded and installed by its users.

Firefox isn’t in any immediate danger. But if Mozilla wants to protect its turf over the longer term, it may want to follow Google in developing a lightweight operating system focused on the web, just as it has started to take the mobile space more seriously in the wake of Mobile Safari and Android.

• Meebo has added some basic Prism support.  Nothing earth-shattering, but this is exactly what we want to see happening, so hopefully it’s the start of a trend.
• Chris Pirillo did a whole manic rant about Prism on CNN video. Thanks, Chris, just note for future reference that our URL (that’s a web address to you and me) is http://prism.mozilla.com (not .org).

Any other interesting Prism sightings? Let us know in the comments!

Mozilla’s caught on to this kind of open-when-needed use, adding built-in support for tray icons (on Windows) or system dock shortcuts (on Macs), along with minimizing the sites to those areas. The other good new things are font control and private data clearing for each window (which was a not-too-small complaint about the previous Prism), and support for notifications and icon updates when you’ve got a new message, chat, or other ping from your web applications (for those sites that support it). I couldn’t quite figure out how to get new mail notifications or icon indicators showing up, but the Prism Features page touts them as present. Anybody want to show us how in the comments?

Like some people’s love lives (if Facebook is to be believed), the answer is: it’s complicated. Adding a tray icon to your application (on Windows) is simple enough. Just set the value of trayicon in the webapp.ini file to true. The application will automatically hide in the tray when you minimize it. Okay, perhaps this wouldn’t pass the “mom test”, but it’s all relative, and making use of many other Prism features is currently less straightforward.

Getting your mail client to display popup notifications when new mails arrive, for example, is more difficult because some knowledge is required of how the web app works. How does Prism know when to display a notification? Either the application has to tell it, or a third-party developer has to use Prism’s customization features to do the same. (If you don’t have at least some notions of and/or interest in software development, you might want to mumble “javascript schmavascript” now and skip to the last paragraph.)

To make the first option possible, Prism defines a new property called platform on the ubiquitous window object found in every web application. Various functions can be called on the window.platform property. (I must admit shamefacedly that the source code browser for Prism is updated only sporadically and is currently a bit out of date, something I hope will be addressed soon.) For example, to display a popup notification you can say:

window.platform.showNotification(

  "My notification",

  "I'm your app and I just wanted to say hi.",

  null

);

Since window.platform is available to web content (as long as the user is running Prism), developers could add statements like this to their apps to make them more Prism friendly. Realistically this is unlikely to happen unless some sort of standardization occurs around this type of API, and browsers that support it become quite popular (both are likely, in my opinion, but not in the short term). In the meantime, a magic file called webapp.js lets you graft code onto an existing web app that adds support for fancy Prism features. (I won’t get into details now since I am planning a tutorial on this topic.)

The bad news is that you need to be a fairly determined and ingenious programmer to get the most out of Prism right now. The good news is that once someone has gone to the trouble of customizing a specific web app, their work can be packaged as a webapp bundle and distributed to other users, much like Firefox extensions. Now that the 1.0 release has given us a robust set of features under the hood, our next task is to foster an ecosystem of webapp bundles for popular web apps, so that end users and not just developers can get the most out of Prism.