Yesterday I posted about an issue using the new Prism for Firefox extension on OS X. Based on a suggestion from Chris Beard, I’ve implemented a workaround that fixes the problem. It’s not the world’s cleanest solution, but it is only needed until the next release of Firefox comes out (assuming that bug 542004 gets cleared for inclusion in that release). The new extension is now live on the add-ons site.
As we prepare to go live with Prism 1.ob3, I should mention that there is an issue with using the Prism extension in Firefox 3.6 on OS X. Prism uses the Firefox runtime (meaning the XUL, XPCOM and other libraries) for apps it creates. There is a small bug in Firefox 3.6 that prevents the libraries from loading on OS X. See bug 542004 for more information. The bug is currently nominated for inclusion in 1.9.2.2 (I guess it’s too late for 1.9.2.1). If someone is reading this and has the power to make this happen, please keep in mind that this issue is currently preventing Prism from running properly in Firefox 3.6 on Macs.
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).
One of the biggest struggles I face every day is information overload, just like most of the people reading this post. As a result I am constantly reassessing the value of various feeds in my RSS reader and viciously pruning the ones I don’t really need. I don’t subscribe to any feed that produces more than 5-10 items a day anymore since the high-volume feeds like Slashdot and Boing Boing, while often fascinating, just make me depressed and stressed as the number of unread items piles up.
The odd man out is Planet Mozilla. As an active member of the Mozilla community, I can’t not subscribe to this feed. Some of the items (probably several a day) are absolutely vital reading for me if I am to do my job correctly. But the volume of postings makes me depressed and stressed in exactly the way I just mentioned. Particularly irksome is the fact that the vast majority (perhaps 90%) of the posts aren’t of interest to me at all.
Before I go further, let me stress how great Planet Mozilla is and what a personal debt I owe to it. When I began blogging in 2004, I had zero readers, and I had to go about building an audience the hard way (i.e. by humiliating link whoring). When I got onto Planet, my audience increased immensely in one fell swoop, and the new readers were mostly highly informed and articulate (exactly the opposite of what you get by being linked to by, say, Robert Scoble). When I started this blog, I was on Planet from the get go, and it was amazing to have such an immediate and high-quality readership.
All this to say that I understand how hard it is to do anything with p.m.o except add more and more feeds to it. Any disruption to the status quo will lead to howls of protest from people like me who benefit from this great resource. But eventually something has to give. Having a big audience is of diminishing value if the volume of the feed is so high that people don’t have time to read (or even scan) most of it.
When I first started begging for Peer Pressure to be added to p.m.o, I was told that there was discussion about splitting it into multiple feeds. I just checked and there are indeed a few smaller feeds (e.g. Planet Firefox) that are more or less a subset of p.m.o. But this isn’t enough to have the flexibility to make a real choice about which items are of interest (at least not for me). Just looking at the 60-odd unread items in my feed right now, I would suggest that the following categories as sensible:
Something I don’t see right now but that I have seen in the past are posts from people who used to be big contributors to the Mozilla community, but now have nothing to do with it and never write about anything to do with Mozilla. In at least one instance I saw a person fitting this description complain when they were removed (they were then reinstated, much to my chagrin). So perhaps a “Mozilla alumni” feed would make sense as well.
This categorization is by no means definitive. My point is that it is possible to categorize the posts. I’d be ecstatic if the feed were split into 10 or so separate feeds along the lines of what I proposed above. The best part is that, due to the caliber of our blog authors, we can count on people tagging their posts intelligently so they can be included in multiple feeds, if appropriate, without muddying the waters. I certainly have no issue whatsoever with leaving Planet Mozilla exactly as it is now (and continuing to add new feeds frequently), as long as separate feeds are available as an alternative.
But that’s just me. Perhaps I’m the only one who sees this as an issue.
Succumbing to overwhelming pressure from the Linux community, I’ve built Prism 1.0b3pre on Ubuntu.
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.
Based on feedback from my last post, I fixed the extension version numbers (including the Firefox maxVersion) in Prism 1.0b3pre. I also decided to build on top of Mozilla 1.9.2 instead of 1.9.1. My policy has been to use the version of Mozilla that underlies the most recent official Firefox release, but in this case I’ve made an exception (hopefully Firefox 3.6 is just around the corner anyway). As Mark Finkle remarked to me, “be ahead instead of behind”, a statement I’m sure conceals some sort of deep Confucian wisdom.
The new builds are in the same place as the old ones:
Quite a few bugs have been fixed since Prism 1.0b2, so I’ve made new builds for Mac and Windows. Please take a look and let me know if you have any problems. Once they’ve been tested a bit, I’ll put them up on the Prism website as 1.0b3.
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
One of the most frequent questions I get about Prism is how to make it work with such-and-such beloved Firefox extension. One thing is certain, to make an extension work with Prism you have to add Prism’s application ID to the extension’s install.rdf file, as described here. The ID for Prism is prism@developer.mozilla.org. The easiest way to install the modified extension is to enable the status bar by setting status=true in your app’s webapp.ini file. You can then select Tools/Add-ons… in the “gear” menu in the status bar and click the Install… button in the dialog. Open the XPI file of your extension to install it.
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:
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).
A number of people have reported crashes when using the Prism 1.0b2 build on Ubuntu. I haven’t been able to reproduce this problem, so I’ve created a debug build for further testing. The first person to get me a usable backtrace of the crash will win: a new car!
Okay, maybe not. But you will surely win the gratitude of scores of Ubuntu Prism fans.
This year’s European MozCamp was held in my home town of Prague. The venue, the Andel’s hotel in Smichov, was perfect: cool-looking interior, convenient location and even surprisingly good food (we are in Prague, after all). Many thanks to the organizers, William and Irina, for choosing Prague and for throwing such a great event.
I gave a talk about why Prism is strategic for Mozilla (download slides).
Web technology’s pace of evolution is vexingly slow, the result of the wide range of browsers (new and legacy) that must support any innovation in order for it to take hold. Even back in the good old days (basically any time before 2005), when only the Netscape lineage of browsers and Internet Explorer were significant, it was still so hard for the two vendors to agree on anything that only a handful of significant improvements made it through: JavaScript and XMLHttpRequest are two obvious examples. CSS has certainly made its mark, but it has taken years for each release to gain widespread adoption (CSS level 3 is still “in development” after more than 10 years). XHTML, which offered huge advantages in terms of markup modularity and extensibility, was essentially stillborn because Microsoft made no effort to implement it in IE.
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.