Gecko and Webkit… Or Firefox and Chrome?

The supposed switch revived a recurring discussion about how Gecko is a pain in the arse to embed, and how it’s a breeze to embed WebKit. Additionally WebKit is young, shiny and buzzy while Gecko is old and supposedly tired.

It is true that Gecko is much harder to embed that WebKit. It is also true that Mozilla is not spending a lot of time helping people who want to embed Gecko (their priority is Firefox), while embedding is the main purpose of WebKit. The natural consequence is that I don’t know any recent project choosing Gecko as their rendering engine.

But that’s not the point. Flock is not embedding a rendering engine, they are taking a full blown browser – currently Firefox – and tweaking it. Flock is not a browser based on Gecko, it is a browser based on Firefox. That explains a lot of similarities between the product, and that also explains why most Firefox extensions work in Flock.

That means that if Flock switches to Chrome (actually Chromium, the Open Source version of Google Chrome), it doesn’t matter how easy it is embed WebKit: what matters is how easy it is to hack Chromium. And it doesn’t matter how responsive and nice the WebKit community is: what really matters is how Google will deal with external contributors and patches from external contributors. And as Chromium is young, this is still unsure.

But even if Chromium appears to be open to contributors, how they would react to a company building an other browser based off Chromium is pretty unknown. It’s just like with Mozilla: they release their code under an Open Source license so they explicitly allow that kind of derivative work and can’t prevent it to happen. But whether they will see Flock with a better eye than Mozilla did is a different question.

Would Flock benefit from a switch to Chrome?

I can really see only one good reason for Flock to switch to Chrome: the “process-per-tag” system.

Flock have always suffered of Mozilla’s single thread, single process logic. For example, when you fetch the Facebook friends list of a rockstar, you have to merge lists of thousands of friends then refresh the UI to reflect that. This operation happening in the main thread (the only thread) it will literally block your browser. To workaround that, Yosh wrote a simple Scheduler that sets timer to yield to the UI once in a while. It’s really a hacky way to get threads-like things, and since we didn’t apply it everywhere there were still code that were freezing the browser. With Chromium, Flock’s sidebars or topbars would run in separate process and be less disruptive for usual browsing.

It’s hard for me to see how that single reason would outweigh the cost of switch for the team and for the users. This is going to be a completely different product with new bugs, features disappearing and alienated users. I do not know Flock’s current strategy but I can only assume they are seeing more benefits to the switch that I can’t see.

Letting the user choose

That kind of controversy about what Flock should use (or will use) as a “host browser” is pretty irrelevant for extensions companies. Foxmarks, CoolIris and the company I currently work for are all examples of companies who provide a rich browser feature while letting the user choose his browser.

At its early days, Flock decided to be a browser instead of a set of extensions. This choice makes sense for Flock’s general strategy, but today I can’t help but think that if Flock was an extension company, it could just have released a Chrome version along with versions for other browsers.

Here are some of the features I added:

• Online presence and chat: no chat in the sidebar yet, but you can already see who is online from the sidebar and initiate a chat from there.
• Contact sorting: at least for Facebook and Twitter, contacts are now sorted by last updated first

Online status for Facebook friends in the Yoono sidebar

• New activity types, from the new Facebook API: you are now notified when your friends post new notes or share links. With the thumbnail:

Shared Links

There is much more coming for Yoono’s friends widget in the next version. I can’t tell anything for now (Yoono’s development is not open), but stay tuned for the 5.5.0!

Media RSS on the French website lemonde.fr

While Flock has been doing a lot of service-specific integration, it has never been the intent for the long term. We do service-specific because we have no choice, but we are eager to support open standards (and promote them) as they get available. Our blog editor had support for MetaWeblog and ATOM Publishing Protocol from the beginning, and now it’s the turn of the mediabar to get some open standard love.

Media Discovery

What does it mean for you, the user? Well, it means that besides the 7 supported services, you can consume content from any website that advertise an RSS feed. You can try it, in Flock 2.0beta2. Here is a selection of websites:

• I can has cheezburger
• Smugmug
• Le Monde (if you can read French)
• And many more! There are so many sites I can’t keep track of all of them.

Custom Search

So when you visit a page with a media rss feed, you can see it in the mediabar and subscribe to it. It gives a experience similar to Flock’s news reader, but with an experience more tailored to media content (images and videos). But there is more. It’s really an advanced feature, but if a website provides a media rss feed for a given search result, you can use that to add search in the mediabar.

Example: Hulu
Hulu is a website with TV content from the major networks (FOX, NBS, PBS…) with limited advertisement. You can get search for it in Flock’s mediabar, again that’s for Flock 2.0beta2:

1. Open the URL “about:config”
2. Search for “rssSearch”
3. Change the value of flock.photo.rssSearch to:
   [{"hulu":{"id":"hulu","title":"Hulu Videos","url":"http://www.hulu.com/feed/search/%s","icon":"http://www.hulu.com/images/hulu.ico"}}]
4. Open the mediabar

Voilà! You can now search for your favorite TV shows in the mediabar.

Search for "Homer" on Hulu.com

Get support for your site

If you have a feed with images or videos on your website/blog, you can get it in Flock’s mediabar pretty easily.

The easiest way is to pipe your feed through Feedburner, making sure you enable their SmartCast feature. Feedburner will nicely add the required markup to your feed (and they have a lot of other features too).

If you’re tech savvy and you’d rather do it your way, there is some documentation that I wrote for that.

In order to minimize the wait between the release of Firefox 3 and a Flock version based on it, Manish and me started to work on porting Flock to FF3. The current stable version of Flock is based on Firefox 2, the latest stable release from Mozilla.

That’s today that we’re very glad to work on overlays, and keep our source modification away from Mozilla files as much as possible. Changes that were touching Mozilla files take way more time to merge/migrate. That’s also an opportunity for us to clean up some of our code. For example, the way we were changing entities in browser.xul was to replace the DTD file. Bad, because we were missing the new entities from Firefox 3. We fixed that to only override the entities we want to change (Firefox -> Flock, Bookmarks -> Favorites…)

So here is where we are after a few days.

What works

• The datastorage layer. The data layer of Flock consists in an RDF datasource accessible through a Javascript object mapper (Coop) and serialized on the disk in a mozstorage (sqlite) database. I don’t know if Manish had to do anything to make it work in Firefox 3, but it seems to be working great.
• The services backend. We had to migrate to the login manager because the password manager is deprecated. So long nsIPassword, the time of nsILoginInfo has come.
• The web clipboard. Not really a surprise, it’s simple enough not to break. Cherry on the cake: now when you drag a picture or a snippet, the whole picture moves with your cursor. That really looks great and make drag’n drop very clear and easy to understand.
• The blog editor. Still some bugs, but the basic functionality is there. Almost no work required!
• The people sidebar. I’m really impressed. This is a big piece of code, but as soon as the service backend was fixed it just worked out-of-the-box. Everything seems to be working.
• The star button. That one was easy. Mozilla is introducing a one-click bookmarking star button (just like the one we’ve been having in Flock for 2 years). So all I had to do is drop our own star, move Mozilla’s one from the right to the left and theme it correctly. Tada! No online bookmark yet and it’s not clear whether we’ll stick with Firefox’ behavior (that’s not yet clearly defined anyway), but it’s a start.

What’s broken

• The theme. I started to fix it, but there is still a lot of work to do. The background on toolbars is missing, tabs and the URL bar need to be styled…
• Full text history indexing. Manish did some work on the Lucene level, and I started to migrate from the History RDF to Places. Not quite working yet.
• The searchbar. I didn’t look at it yet, but as you can see on the screenshot it’s not pretty. Maybe it will just work after we fix the theme and the indexer?
• Online bookmarks (Delicious, Magnolia). They do get synchronized locally but don’t appear in the UI yet. With Places we’re basically throwing away most of our UI favorites code, but we need to reinject the code related to online bookmarks in the Places UI.
• Mediabar. It’s pretty much busted. We’ve been using hacks and non-standard techniques more than in any other modules; I suspect that most of the breakages are due to things we were not supposed to do even in Firefox 2, and we may have to redesign some pieces to do it “the right way”.
• Notifications. I reverted that change because it was preventing the browser to start (“can’t find the XBL for browser”: hard to use it when the browser window doesn’t appear!). Manish is going to take care of it, and that’ll probably end up being a simple change.

I recommend to anyone coding on the Flock browser to have a look at Mozilla’s page about porting extensions to Firefox 3. In particular, there are points about stuff that work in Firefox 2, but that we were not supposed to use and will stop working in Firefox 3. For exemple, event.preventBubble deprecated in favor of event.stopPropagation. If we start to be careful about these points in Flock’s trunk, the migration to Firefox 3 will be much smoother.

And if you want to play with a broken browser… Feel free to build the branch experimental/firefox3-merge.