A narrative on the future of web browsers and web browsing

Prism and the Open Web Store

May 24, 2010 – 5:04 pm

Responding to Google’s announcement last week of a Chrome Web Store, Jay Sullivan asks on the Mozilla Blog for ideas about an alternative Open Web App Store. This is something that I’ve been thinking about and discussing with Mark Finkle for a couple of years now in the context of Mozilla Prism. In fact, I originally wanted to launch the first Prism 1.0 beta with a “web app bundle library” that I think closely mirrors what an Open Web App Store might look like (and I blogged about this over a year ago). While at the time I succumbed to the realities of resource constraints and abandoned the idea, perhaps the time is ripe to revive it.

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.

Prism 1.0b4, Fixes Rare Windows Registry Issue

May 5, 2010 – 6:31 pm

A while back I blogged about a rare issue that occurred if a user clicked on the regprot.exe file included in Prism to handle protocol handler registration. I thought the issue had been fixed ages ago, but a couple of recent reports have led me to believe that it can still occur in some cases, although I haven’t been able to reproduce it on my computer. This is obviously a serious problem even if it only occurs in unusual circumstances when the user clicks on regprot.exe (something that shouldn’t ever happen in the course of normal use of Prism). If anyone has experienced this problem, repairing Windows using the installation CD can apparently help.

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

Wanted: C++ Developer in Prague for Mozilla-Related Projects

March 26, 2010 – 5:25 pm

I’ve been doing freelance development for the past two years for various clients. All of the projects I currently work on are related to Mozilla technologies (Prism, Firefox extensions, etc.). Business is booming, and I would like to hire someone to help me keep up. The only two hard requirements are for someone who is living in the Prague area and is a very talented, motivated software developer. Advanced C++ skills are a big, big plus. Also great: experience with JavaScript, Firefox extension development, Mozilla build system, XULRunner, Unix environments, Mac, Windows and OS/2. Yes, I’m kidding about OS/2.

The ideal person would be a young C++ developer/Unix hacker with some experience with and especially a lot of interest in working with Mozilla technologies. I can offer awesome conditions (flexibility, compensation, challenging projects, opportunities to learn tons of new stuff).

If you’re interested, please email me your CV. If you know someone who might be interested, please pass the word.

Prism for Firefox 3.6 on OS X, an Update

February 10, 2010 – 5:58 pm

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.

Prism, Firefox 3.6, OS X and dependentlibs.list

February 9, 2010 – 5:28 pm

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

Thoughts on Planet Mozilla

January 20, 2010 – 10:12 am

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:

  • Firefox development (present and future)
  • Third-party developers using Mozilla platform (including Messaging, Seamonkey)
  • Mozilla marketing and the browser market
  • Mozilla licensing and open-source in general
  • Mozilla Foundation
  • Testing
  • Employee status updates
  • Extension development and AMO
  • Mozilla Labs
  • Mozilla server admin
  • Meeting minutes
  • Documentation
  • Non-Mozilla posts by Mozilla folks (employees and community)

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.

Ubuntu Build of Prism 1.0b3pre

January 18, 2010 – 4:10 pm

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.

New Prism 1.0b3pre Build, Now With Mozilla 1.9.2

January 15, 2010 – 2:56 pm

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:

Download Prism Standalone Version for Mac or Windows

Download Prism for Firefox extension for Mac or Windows

Prism 1.0b3pre Available for Testing

January 11, 2010 – 5:07 pm

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

Prism and Extensions

October 22, 2009 – 5:21 pm

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:

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