QRChrome Extension

So far, here is what I have been able to do:

• Add a page action icon in the URL bar
• Open a new tab with the QR Code for the URL you want

It seems straight-forward but the browser don’t seem to behave exactly as documented, and I didn’t found anyway to debug – at least on Linux. I assume it works better on Windows.

Here is what I want to do before the extension can be really useful:

• Just like the Mobile Barcoder, Show a popup on hover rather than opening a new tab.
• Add a item in the link context menu, so the user can generate a code from a link – not just from the URL bar. Useful for download links.
• Package the extension! That may sound stupid, but extensions are packaged from Chrome directly – and it doesn’t work on Linux. It’s not something you can do from command line… Well, actually you can package from command line but using the Chrome binary and that doesn’t work either

PS: The feed icon is a sample extension from Google. I don’t understand why it’s not in the core.

Alas, it doesn’t work. Since a bunch of stuff is still missing from the Linux builds, I guess extensions don’t work either.

Did anyone manage to get extensions working on Chromium Linux? Is there a flag or something to add at compilation time?

The difference for my recent sandboxed Video Games Spy (a sidebar to get aggregated info about games) is huge. It went from 0-ish to more than 50 downloads a day! It’s still not a lot, especially compared the thousand a day Moji is still getting, but it shows there is some interest for the add-on.

Super Mario Galaxy!

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.

I’ve been living for about 4 years in Tokyo to do my Ph. D. After that, I moved to the Silicon Valley to join Flock, at the time a tiny startup operating from a garage in Palo Alto.

Termie, Rockstar Programmer at the Original Flock HQ (by foolswisdom)

Today it’s time for me to say goodbye to my friends at Flock, but I will never forget the 3 years spent working on the web browser. I’ve seen the company at various stages, growing from the days of the garage with the founders to a bigger team, split between two offices with a professional CEO.

I’ve also had the chance to enjoy Northern California: the blue sky, the geek-friendly environment, the numerous tech-related events, the Japanese supermarkets, the burritos… More importantly, I’ve met with some really smart engineers from whom I’ve learned a lot, and it has been a real pleasure to work with them. I’m convinced that I’ll stay in touch with these friends even living 9,000 km and 9 time zones away from the Valley. (And that’s true for non-engineers too )

***

So as I said, I am moving to France and while I have great memories with Flock, it is also time for me to look forward. The good news is that I found a very exciting project to join, and I will start in that new company as soon as I land in Paris early next year. It’s called Yoono, and the eponymous product is a browser extension with some similarities with Flock’s own features. It’s a great opportunity for me to keep one foot in the Mozilla community (the extension runs on Firefox) while still exploring new things such as extensibility on other browsers (Yoono runs on IE too) and server-side work (Yoono is coupled to a web service).

If you were following what I was doing at Flock, you probably want to check out Yoono. It’s really one of the most advanced browser extension out there.

It is about the options for text and icons on toolbars. Currently, Firefox proposes three options:

• Icons only (the default)
• Icons and text
• Text only

Gnome and Toolbars

Gnome, on the other hand, has one more option: text besides icons, while the icons and text option of Firefox is called text below icons. My preference goes to text besides icons. Let’s see how each option looks on Epiphany, Gnome’s own web browser:

Gnome's different toolbar options on Epiphany

From top to bottom: text below icons, text besides icons, icons only and text only. As you can see, in the “text besides icons” option, not all icons have a label: only the most important ones. It’s not unlike IE6, so IE6 was not completely garbage. Yes it has a shitty rendering engine, no tabs and no popup blocker, but it has text besides icons .

The advantages of “text besides icons” are multiple, not limited to teaching the meaning of the buttons but also:

• Create a hierarchy between important buttons and secondary buttons (for example, “back” is more important than “forward”
• Give more real estate to important buttons, making them easier to click

Those two goals have been solved for Mac and Windows for the back and forward buttons only; however on Linux back and forward are still given the same importance.

I believe the patch would be simple enough, it is just one entry to add to the options list and and few CSS rules to apply in this case (see below).

The Cherry on the Cake

If Firefox get that feature, the cherry on the cake would be to have an additional option for Linux users: “System Default”. Using this option, Firefox will just use whatever the user (or the distribution) set from the preferences. It would be tempting to get rid of the option altogether and set everyone to the system default, but I guess that wouldn’t please KDE users who don’t have access to this preference.

That requires (1) to read the gconf option for toolbars and (2) to listen for the change in order to refresh the UI as soon as the user changes the system preference.

It seems like the Mozilla codebase already have some code related to gconf, in nsGNOMEShellService.cpp to set Firefox as the default browser.

Get it Today

You can easily get the text besides icons on your Firefox, by adding the following lines to your userChrome.css:

/* Text besides icons */
toolbar:not([mode=full]) #back-button,
toolbar:not([mode=full]) #home-button {
   -moz-box-orient: horizontal !important;
}

#back-button .toolbarbutton-text,
#home-button .toolbarbutton-text {
   display: block !important;
}

You will have to set your toolbars to “icons only”.

Text Besides Icons in Firefox

But where does the term Godzilla come from? It’s a contraction from Gorilla and Kujira. Let’s be clearer:

• Gorilla (ゴリラ): yep, like in English, a pretty big and strong ape
• Kujira (鯨・クジラ): a whale, pronounced “kujila”

Gozilla is written in Japanese ゴジラ, pronounced “gojila”. I guess it’s supposed to mean that he’s as strong and fierce as an gorilla, and as big as a whale.

In short, by attacking any -zilla suffix (and winning), it looks like Toho actually owns the Japanese word for “whale”.

While it’s very natural on Linux, I don’t think it’s reasonable on Windows and Mac to expect multiple application to run on the same runtime. That would force Mozilla to keep backward-compatibility, and that’s a big pain in the neck. Ask Microsoft about backward compatibility in Windows: over the year, they had to simulate bugs from older Windows versions to prevent breaking older applications.

Imagine Firefox 3.1 is released, and requires a newer version of XULRunner. You install Firefox 3.1, in order to do that you upgrade your XULRunner. Well, the Songbird folks may not have tested their bird with the latest XULRunner, and it may break. If it does, you’re stuck: either you give up on the latest Firefox, either you give up on Songbird.

That works on Linux because a single actor (the distribution) gets to pick what version to include, test to make sure it works, and patch stuff if necessary. In the Windows and Mac world, there is no one single repository and people get their software directly from upstream, so if you go down the path of dependencies it’s going to be a hell of conflicts… Unless Mozilla guarantees a full backward-compatibility, which is a lot of work because it requires testing.

Of course, that doesn’t mean applications shouldn’t be designed to allow runtime sharing. But I can guarantee that even when that happen, everyone (Firefox, Songbird, Thunderbird) will be bundling their own XULRunner runtime, just like they’re doing today… Except for the Linux distributions.

My application as a AMO editor has just been accepted!

I will now be reviewing Firefox extensions and themes, for the benefit of users and developers. Extensibility is a killer feature of any product based on Mozilla technologies, but it’s so powerful that it can be dangerous. Extensions can do whatever the hell they want, and that includes breaking a browser or do nasty things. The AMO editors must only show extensions that work correctly, don’t break the browser, and don’t invade the user’s privacy.

Especially after the launch of Firefox 3, most extension had to be ported, and a lot of new developers are coming to the platform, increasing the workload for AMO editors. I will be helping the AMO team to get quality addons in the front of users, while teaching developers what they should do to reach the quality level expected by AMO.

Note that, while the technologies involved are the same, this is independent from my day job. I will be reviewing extensions as an individual, not as an employee of my employer.

• Mark Finkle, in charge of the developer community
  
• Dan (Thunder) and Seth, who not only share my interest for the Japanese language but also work on Places, the bookmarks system of Firefox 3 (since I’m now working on Flock’s favorites system I have a great interest in Places)
• Mike Shaver of AMO
• Alex Vincent of the verbosio project
  

…and a lot of other great people. Here is a few of the things that I learned:

• rikaichan is a great Japanese dictionary extension, complementary to my baby Moji
• Mozilla have one full time developer community guy (Mark Finkle) and one full time community-given program leader (Seth – his task is to distribute resources to volunteer contributors)
• There are about 4 to 5 people working part time on Places. The back-end is the cool innovative stuff, going in Flock’s direction (tagging, integral text indexing…) that they’ve always wanted to build, but the UI is conservative: the good old boring bookmark UI that you can find in Firefox 2.0. They will innovate from that after they get parity with the old bookmark system. However they don’t use the URL as a key. If you bookmark the same page twice, you end up with two distinct instances.

Thanks a lot to all the Mozilla folks – that was a great day. I’m looking forward for the next.

Blogged with Flock