The Japanese version is also available at modest.

Recently Mozilla Labs Jetpack site was updated and Jetpack Reboot was finally revealed to the public. However, not a few people might think that “What’s Jetpack Reboot? How does it differ from the old Jetpack?”.

Briefly speaking, the old Jetpack (Jetpack Prototype) which has being developed as a Firefox extension, will disappear in the near future, and now it is being replaced to the new Jetpack (Jetpack Reboot) as a brand-new SDK to build new type of extensions.

This post explains the difference between Jetpack Prototype and Jetpack Reboot with three points of view: concepts, architecture and development.

(1) Concepts

There’s no much difference between the basic concepts of both types of Jetpack. Jetpack Reboot has the following concepts as the superiority of extensions utilizing Jetpack Reboot SDK in comparing with the existing commonly-distributed extensions:

• Web developers can easily develop in their familiar languages: HTML, JavaScript and CSS
• Rapid development using rich API library to ease our debug and maintenance
• A robust security model to keep users away from their security risk
• No need to restart Firefox when installing and uninstalling

(2) Architecture

See the image below which describes the architecture of both types of Jetpack.

In Jetpack Prototype, you need to install Jetpack “extension” which consists of a runtime and API library, and each small program called Jetpack Feature works on Jetpack extension. There seemed to be a plan to integrate Jetpack extension into Firefox. However, it may cause a problem that the integration prevents the agile development of the evolving API library. Additionally, since all features share one API library, it may cause a compatibility problem if each feature uses a different version of API.

Meanwhile in Jetpack Reboot, Firefox doesn’t hold the API related to Jetpack, and each feature becomes a package including the API and bootloader. This architecture enables the agile API development and the API included in each package are not interfered even if they have differing versions. We can distribute the package as an XPI installer same as the existing XUL-based extension. So, we can install and uninstall it in a same way of the existing extension. Additionally, in the future the Firefox extensions manager will be improved so that we will be able to install and uninstall the packages which have Jetpack bootloader without restarting Firefox.

(3) Development

Shifting from Jetpack Prototype to Jetpack Reboot changes the style of extension development. In Jetpack Prototype, we can easily build a feature by making single JavaScript program. Meanwhile in Jetpack Reboot, we need to utilize a development environment called Jetpack SDK and make a package of JavaScript program and JSON-formatted manifest file in the appropriate folder structure. The current version of SDK 0.1 is a command line tool made with Python language. Although the new development style seems to be more likely for the advanced users than the old one, there is a plan to make it easier with a GUI development environment called FlightDeck which works on your browser.

Note that the current SDK doesn’t have rich API to build working extensions like Jetpack Features, since it is in an early stage. I will post a step-by-step tutorial to make a package utilizing the SDK on Windows 7 before too long.

I like mouse gestures, but All-in-One Gestures and Optimoz Mouse Gestures both have too much unwanted features for me. I tried to reduce unwanted parts from AiOG but I gave up since the original source codes was very complex.
And so, I made it by myself from scratch as a small user script for userChrome.js extension, which has only less than 200 lines.

xuldev.org :: userChrome.js scripts » Mouse Gestures

Major features

1. No mouse trails. Because it would be one of a factor to be slow down the gesture. Nonetheless we can implement it by picking ‘trails.js’ from AiOG.
2. As much as possible, it executes the ‘built-in’ commands of Firefox itself when we perform actions by gestures.
3. No options dialog. But we can economically and flexibly customize by editing the script directly. For more details, please see ‘_performAction’ method in the script below.

Japanese version of this post is also available.

nsIRDFObserver enables us to observe various events occurred at nsIRDFDataSource. The Firefox’s Bookmarks is managed internally as nsIRDFDataSource, so we can inspect it with nsIRDFObserver described below and Error Console (formally known as JavaScript Console).

First, you should define nsIRDFObserver object which observes the datasource. The two methods, “_targetToString” and “_log” are defined as original private methods.

var rdfObserver = 
{
    onAssert : function(aData, aRes, aProp, aTarget)
    {
        this._log(["onAssert", aData.URI, aRes.Value, aProp.Value, this._targetToString(aTarget)].join("
"));
    },
    onBeginUpdateBatch : function(aData)
    {
        this._log(["onBeginUpdateBatch", aData.URI].join("
"));
    },
    onChange : function(aData, aRes, aProp, aOldTarget, aNewTarget)
    {
        this._log(["onChange", aData.URI, aRes.Value, aProp.Value, this._targetToString(aOldTarget), this._targetToString(aNewTarget)].join("
"));
    },
    onEndUpdateBatch : function(aData)
    {
        this._log(["onEndUpdateBatch", aData.URI].join("
"));
    },
    onMove : function(aData, aOldRes, aNewRes, aProp, aTarget)
    {
        this._log(["onMove", aData.URI, aOldRes.Value, aNewRes.Value, aProp.Value, this._targetToString(aTarget)].join("
"));
    },
    onUnassert : function(aData, aRes, aProp, aTarget)
    {
        this._log(["onUnassert", aData.URI, aRes.Value, aProp.Value, this._targetToString(aTarget)].join("
"));
    },
    /**
     * refer to an appropriate interface for nsIRDFNode and get the string-type value
     */
    _targetToString : function(aTarget)
    {
        const Ci = Components.interfaces;
        if ( aTarget instanceof Ci.nsIRDFLiteral )
            // String type
            return aTarget.QueryInterface(Ci.nsIRDFLiteral).Value;
        else if ( aTarget instanceof Ci.nsIRDFInt )
            // Number type
            return aTarget.QueryInterface(Ci.nsIRDFInt).Value;
        else if ( aTarget instanceof Ci.nsIRDFDate )
            // Date type
            return aTarget.QueryInterface(Ci.nsIRDFDate).Value;
        else
            // And more...?
            return "";
    },
    /**
     * output string to Error Console
     */
    _log : function(aMsg)
    {
        const CONSOLE_SERVICE = Components.classes['@mozilla.org/consoleservice;1'].getService(Components.interfaces.nsIConsoleService);
        CONSOLE_SERVICE.logStringMessage(aMsg);
    },
};

Then, the only thing you have to do is adding the observer to Bookmarks datasource.

// get the datasource of Bookmarks
const RDF_SERVICE = Components.classes['@mozilla.org/rdf/rdf-service;1'].getService(Components.interfaces.nsIRDFService);
var BMDS = RDF_SERVICE.GetDataSource("rdf:bookmarks");
// add the observer to datasource
BMDS.RemoveObserver(rdfObserver);
BMDS.AddObserver(rdfObserver);

References：
Interface Reference – nsIRDFObserver
Interface Reference – nsIRDFDataSource

Japanese version of this post is also available.

The 2nd topic in the series, “Rethinking ScrapBook’s Browser Context Menu”.
This time, I kick around the [Capture Frame] menu which apprears with [Capture Page] when we click in a frame / inner-frame. In the Firefox’s standart context menu, all menus related to frame are submenus inside the [This Frame] menu. Hence [Capture Frame] should be inside the [This Frame] menu in a similar way.

Contorary to that, the standpatters might have such viewpoints:
Additional menus of extensions should not scatter and should be placed in one place.
It is easier to choice between [Capture Page] and [Capture Frame].

As a developer, I have a following viewpoint. [Capture Frame] inside [This Frame] is surely sensible, however, I’m afraid some people mistakenly thought that [Capture Frame] was gone!

Please let me hear your thoghts or comments.

Current: [Capture Frame] and [Capture Page] are in parallel position.

Alternative: [Capture Frame] should be the submenus inside [This Frame].

Japanese version of this post is also available.

The 1st topic in the series, “Rethinking ScrapBook’s Browser Context Menu”.
First time, I kick around the most popular [Capture Page] and [Capture Page As…] menus.
Today we have these menus at the bottom of the browser context menu. However, the feature of [Capture Page (As…)] is similar to Firefox’s [Save Page As…] one, so they should be ‘neighborhood’ each other. At least, both should be placed in a same category between two separators.

Contorary to that, the standpatters might have such a viewpoint: additional menus of extensions are below Firefox’s standard menus in rank.

Please let me hear your thoghts or comments.

	Current We have [Capture Page (As…)] at the bottom.
	Alternative [Capture Page (As…)] and [Save Page As…] should be placed in close position.