Voldzilla

Old School To Jetpack Part 2 - XUL Bashing

2013-05-16T00:00:00-07:00

In Old School to Jetpack Part 1 I briefly mentioned that xul overlays are not supported with Jetpacks, so today I want to talk about how to convert old school XUL overlays.

A typical overlay would look something like lke this addon-browser-overlay.xul:

<?xml version="1.0"?>
<overlay xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
  <toolbar id="addon-bar">
    <textbox id="test-status-bar-message" insertbefore="addonbar-closebutton" value="Hi!"></textbox>
  </toolbar>
</overlay>

This overlay, would then be associated to browser.xul in the chrome.manifest file with an entry like this:

overlay    chrome://browser/content/browser.xul chrome://{add-on name here}/content/addon-browser-overlay.xul

Finally, the overlay would produce this in Firefox’s addon-bar:

With Jetpacks however the latter step cannot be done, because these overlay entries are ignored for restartless add-ons. One could manually force the overlay with a call to document.loadOverlay, but there is no way to undo this, that is why overlay’s are not supported for restartless add-ons at the moment.

So what is needed here is a module that will add the desired XUL elements to the desired XUL documents.

This is why I wrote a XUL package for Jetpack, it is very raw at the moment, and very simple, so you’ve been warned!

XUL Package for Jetpack

About

The source code can be found on github here.

Pros

Quick easy solution for coverting XUL overlays for use with Jetpacks
Handles unloads

Cons

Only works on Firefox (or other applications made with XUL)
At the moment this package only works for adding xul to browser.xul (although it won’t be hard to extend)

Alternatives

Before I go in to this module I want to take a moment to point out that there are many third party packages which handle most of the use cases that overlays for browser.xul support; they don’t cover everything though, like the example above, so this is why I wrote this general purpose package.

Usage

To implement the example above using this module, one would simply need to do the following:

const { XUL, getXULById } = require('xul/browser');
getXULById('addon-bar').insertBefore(XUL('textbox', {
  id: 'test-status-bar-message',
  value: 'Hi!'
}), 'addonbar-closebutton');

And this code is restartless!

Old School To Jetpack Part 1 - The Retrofit

2013-05-12T00:00:00-07:00

Old school add-ons were developed with a similar mindset, which is that creating new windows is ok, and using XUL this became an easy to-do common practice. The times have changed, and opening new windows is no longer considered acceptable practice, opening tabs is now the preferred user experience.

Now, Firefox has a huge cast of popular, restart addled, old school mannered add-ons, which is a problem. So how do we retrofit these geezers?

I see three parts that need to be addressed:

New XUL windows (windows created by the add-on)
XUL overlays (content added to windows created by Fx or another add-on)
Back-end logic

I plan to write more about all three topics later, because the real solutions require more words and work than the shortcuts will.

Shortcuts

Chrome.manifest

Because of Bug 559306 we can now include the old school add-on’s chrome.manifest file in jetpacks. There are some limitations however, for more information on that see this page on the chrome.manifest in restartless add-ons. For instance, overlays will not be regestered, resource uris, components, and more. One can register a chrome uri however, with a skin and locale.

This means that add-ons which implement XUL windows can continue to use them as a Jetpack.

These windows should be redesigned however, but this is no longer a bar to entry, and the resdesign of these windows can be done in a separate step from the conversion to Jetpack.

Also, remember that any windows open which are associated to an add-on should be closed when the add-on unloads, if you do not do this then your add-on will not pass a full review on addons.mozilla.org.

Browser UI

Again, there are a few useful third party modules which handle most common use cases, and if they do not cover your use case then they should provide some direction how to implement them.

I’ve got a module in mind that should help with converting overlays, it’s a messy prototype right now though, so we’ll see how that goes..

Components

There are a few useful third party modules out already which handle things like registering custom uris (this includes about: uris, resource: uris, and whatever:), content policies, and in many cases there are better alternatives. For instance I’ve seen quite a few add-ons register components just in order to hear their ‘startup’ event, this is no longer necessary, with a Jetpack you can simply call require('self').loadReason in main.js.

Blocking Content With Jetpacks

2013-05-11T00:00:00-07:00

Many of the most popular add-ons have a common function, they block content. Adblock Plus blocks ads, NoScript blocks scripts, and Ghostry blocks tracking software which uses images, scripts and other means to do their business.

This is why I wrote a content-policy module for Mozilla’s Add-on SDK. The API is rough at the moment, and I plan to change that quite a bit. For the moment though we can take the No Google Analytics add-on as an example source here:

lib/main.js

const { ContentPolicy } = require('content-policy');
const GA_REGEX = /(.*\.)?google-analytics\.com$/i;
const { URL } = require('sdk/url');

ContentPolicy({
  shouldLoad: function({ location }) {
    // if the hist is google-analytics.com then block it
    if (URL(location).host.match(GA_REGEX))
      return false; // returning false rejects the request before it starts
    return true; // returning true does not reject the request
  }
});

I’ll improve the match later, but you can see how easy that is, and I promise I’ll make it easier.

The Per-Tab Private Browsing Plan

2013-03-06T00:00:00-08:00

Will Bamberg wrote about Per-window private browsing and the Add-on SDK recently, and I wanted to follow up with a quick note about Per-tab private browsing on Fennec.

The situation is almost identical to Firefox’s, except that Fennec never had global private browsing implemented which is basically the same as having global browsing off, so the transition to per-tab private browsing is essentially the same as that for per-window private browsing.

You will have to repack in order to support Firefox 20 for mobile (aka Fennec 20), and you will have to request private-browsing permission (as Will outlines in his post) in order to be aware of private tabs. If you don’t opt-in for private-browsing permission, then you will not see private tabs in the tabs module and you will not be able to add a page-mod to private tabs for example. If you do request private-browsing permission then you will need to check if the tabs that you handle are private like so:

require('sdk/private-browsing').isPrivate(tab)  // returns true if the tab is private and false otherwise

The code examples that Will provides are jsut as relevent to per-tab private browsing as the are to per-window private browsing, so give his post a read!!

Also if you have private-browsing permission, then you can open a private tab like so:

require('sdk/tabs').open({
  url: "https://mozilla.org",
  isPrivate: true
})

If you use the above example on Fennec, a new private tab is opened, if you use the example code on Firefox then the tab will be opened in a private window, which may not be the most recent active window.

If you don’t have private-browsing permission, then using the isPrivate flag when opening a tab or window, then it will be ignored.

No Google Analytics For Firefox

2013-02-16T00:00:00-08:00

Sometime during the last weekend I managed to spend a night trying to use nsIContentPolicy (which allows one to observe network requests before they start and possibly reject/block them) in a jetpack for Firefox.

NO Google Analytics

In a strange flash of inspiration I made NO Google Analytics, which is using nsIContentPolicy to block requests for the ga.js javascript file that collects your information and stores it in cookies, and this add-on will block requests for Google Analytics __utm.gif which is used to transport the tracking information to Google. Often this __utm.gif image is referred to as “the invisible gif” because it is only 1 transparent pixel, and it can be used to track users even without ga.js which many users of NoScript already block thinking that does something, and webdevs have long ago worked around.

The source code and issue tracker for this add-on is on github.

Comparison to Google Analytics Opt-out add-on

Google provides a Google Analytics Opt-out add-on, which they claim will do the following:

The add-on instructs the Google Analytics JavaScript not to send any information about the website visit to Google Analytics.

The problem with this is that their code is not open source, and it is not reviewed by anyone because Google doesn’t want it to be. They just want you to trust them, so do you?

Anyhow Google doesn’t even claim to block anything, so webdevs can still work around this opt-out add-on so far as I can tell.

Thanks Alex and Loic

I big thanks needs to go out to Alex Poirot and Loic Duros, their previous exploration using nsIContentPolicy meant I had to do very little to get this add-on working.

On that note I’ve started a content-policy module to expand on the work Loic and Alex have done and make it easier to reuse, the module can be found on github as usual, and I will be blogging about it more after I write some tests and documentation for it.

The Per-Window Private Browsing Plan

2013-01-30T00:00:00-08:00

Due to Per-Window Private Browsing (Bug 463027) there will need to be substantial changes to the Add-on SDK.

The Add-on SDK team is tasked with making it easy to make add-ons. One way we achieve this is by abstracting away the Gecko platform’s complexity, and saving add-on developers from platform changes from one version of Firefox to the next, but this won’t always be possible and per-window private browsing is one of those changes that we won’t be able to abstract away to the point that upgrading an add-on that was based on version 1.13 or earlier to v1.14 would be possible.

To put the change simply, before with global private browsing a add-on developer need only know if the mode was active or not and when that state changed, now with per-window private browsing none of that information is available because it no longer exists. With per-window private browsing a add-on developer will need to know if the information they are handling came from a private-browsing window and either ignore it, handle it sensitively, and possibly do some extra cleanup work for the sensitive data when the associated window is closed, or when the last private browsing window is closed. The best approach to take depends on the use case.

For the Add-on SDK this means the private-browsing module’s old events (start and stop), methods (activate and deactivate), and attribute (isActive) won’t do anything. The latter two will be around and simply throw depcrecation errors if one tries to use them. There will also be a new event exited which will fire when the last private browsing window is closed, and a new method isPrivate which one can pass a tab, window, page-mod worker instance, and perhaps some other argument types will need to be supported as well to make development life easier. For intance one could get the tab for a page-mod worker instance and call isPrivate(worker.tab) instead of isPrivate(worker) but the latter is clearly easier to understand.

The big problem lies in the fact that we can’t simply upgrade add-ons from the SDK v1.13 to v1.14 but we still don’t want to be in a situation where developers are either forced to do a bunch of work to support the SDK v1.14 and Firefox 20+ in turn, or their add-on no longer works on the latest version of Firefox! So we’ve decided that by default add-ons made with SDK will no longer work in private windows, and inorder to support private browsing windows a developer will have to include a "private-browsing": true flag in their add-on’s package.json file.

This way we still can upgrade add-ons, and give developers some time to support this new feature.

Watch for these changes in our weekly beta releases!

Per-Window Private Browsing for Add-ons

2013-01-18T00:00:00-08:00

Per-Window Private Browsing is coming soon (Bug 463027), and for addon developers this is going to mean a lot of work.

I’m going to be writting about the work being done for the Addon SDK soon, but for now I wanted to write some notes down for old school developers, because I think the change is going to be a painful one for some of us. When I think about the changes that I’m going to have to make to Scriptish I get a bit queasy.

First of all, the global private browsing service, nsIPrivateBrowsingService, is being deprecated, so a dummy service will still exist in it’s place for a few versions of Firefox. This is mainly because I didn’t see this change coming a long time ago when the SDK team would have needed to in order to correct older versions of the Add-on SDK (before they were released) so that they wouldn’t break when nsIPrivateBrowsingService is ripped out.. It turns out there are some important add-ons that are mainly used on Firefox nightly builds, and they all broke when nsIPrivateBrowsingService was removed. So would any other add-on using nsIPrivateBrowsingService too though of course.

Alas, here we are with a dummy service, which means that add-ons developers have 3 options:

Raise their add-on’s menVersion supported to Firefox 20, remove the old nsIPrivateBrowsingService code and only support per-window private browsing.
Support both global private browsing and per-window private browisng via code forks by Firefox version.
Support both global private browsing and per-window private browisng via feature detection.

The first two are easy to understand how to do so I won’t bother explaining those, the latter I have a code snippet for:

let pbService;
let PrivateBrowsingUtils;

// get the nsIPrivateBrowsingService if it exists
try {
	pbService = Cc["@mozilla.org/privatebrowsing;1"].
	          getService(Ci.nsIPrivateBrowsingService);

	// a dummy service exists for the moment (Fx20 atleast), but will be removed eventually
	// ie: the service will exist, but it won't do anything and the global private browing
	//     feature is not really active.  See Bug 818800 and Bug 826037
	if (!('privateBrowsingEnabled' in pbService))
	  pbService = undefined;
} catch(e) { /* Private Browsing Service has been removed (Bug 818800) */ }

try {
	PrivateBrowsingUtils = Cu.import('resource://gre/modules/PrivateBrowsingUtils.jsm', {}).PrivateBrowsingUtils;
}
catch(e) { /* if this file DNE then an error will be thrown */ }

// checks that global private browsing is implemented
// if the global private browsing service dne here then it dne at all or it is a dummy
let isGlobalPBSupported = !!pbService;

// checks that per-window private browsing is implemented
// if the global pb service dne but the PrivateBrowsingUtils.jsm exists then assume
// is enabled.
let isWindowPBSupported = !isGlobalPBSupported && !!PrivateBrowsingUtils;

The last two variables defined here namely isGlobalPBSupported and isWindowPBSupported will tell you what is supported.

I’m sure a lot of people will say option 1 or 2 is the way to go, but I have to update Scriptish soon and I know that for me option 3 is really the only option for the short term, long term I’ll do option 1.

I’ll be writing about the changes that will be required for the Add-on SDK soon too.

Floating Scrollbar Jetpack

2012-10-02T00:00:00-07:00

Paul Rouget created a little hack to finally give us floating scrollbars in Firefox today, so it was easy to convert that into a Jetpack for all to enjoy!

Floaty Scrollbar for Firefox

SU.12

2012-09-30T00:00:00-07:00

This Week

Bugs

bug 798090 - Started work on this while reviewing Bug 791577. I’m looking forward to completing this because it will allow me to get back to work on the simple-prefs module. There have been a few feature requests piling up for that module which would be very nice to finally closed.
bug 794310 - Implement contentType for tabs on Fennec

Reviews

Bug 791577 - Support “test” add-ons
Bug 788245 - Document simple-prefs localization

Misc

Setup Windows and Ubuntu VMs for testing.
More work on Next add-on which basically works now but it needs some styling.
Wrote a blog post on the windows and tabs implementation for Fennec.
Wrote an example add-on using the tabs module for Fennec, which is called Tab Usage Stats

Windows And Tabs In Fennec

2012-09-24T00:00:00-07:00

My work on the windows and tabs module support for Fennec has landed! finally.

There are many differences between the two platforms related to windows and tabs, so that’s worth writing about, but most of these things are minor and I’m guessing that most use cases for the windows and tabs modules are covered for Fennec now!

What Works

windows

Typically one wants a reference to the activeWindow, that works. Why do they want a reference to the activeWindow? Well, probably to see what tabs it has, activeWindow.tabs, that works. One might also want to loop through the open windows for each (let window in require('windows').browserWindows) that works as well.

tabs

Tabs are more interesting than windows. On Fennec, you can’t open windows, so tabs are the next option, and it is the better option anyhow, so forget about using windows in any add-on that you develop, please.

var tabs = require('tabs');
tabs.open('https://mozilla.org') // works

Opening tabs works.

tabs.open({
  url: 'https://mozilla.org',
  inBackground: true,
  onReady: function(tab) {
    tab.attach({
      contentScript: 'alert("hello tab ;)")'
    });
  }
});

Opening tabs, and saying hi via content script when the tab is ready, works.

for each (let tab in tabs) {
  tab.url = 'https://mozilla.org';
}

Sending all open tabs to mozilla.org works!

tabs.on('activate', function(tab) {
  borg.consume({
    url: tab.url,
    index: tab.index,
    title: tab.title,
    isPinned: tab.isPinned
  })

  tab.close();
});

Sending the Borg all of the data on the pages you read, works!

Oops.

What Doesn’t Work

windows

Since Fennec only has a single window, attempts to open new windows, and closing the only available open window had to be prevented. This means:

require('windows').activeWindow.close() won’t do anything.
require('windows').open(URL) won’t do anything.

I thought long and hard about this. It was suggested that open would open a tab instead, then I thought about making fake windows, with fake tab collections consisting of a tab subset based on how the window was created. In this latter case, require('windows').open({url: URL, onOpen: function(window) window}), The window would be a fake window object, the window.tabs would be a subset of require('windows').activateWindow.tabs. This would mean that window.close() would only close the tab for URL.

It wasn’t a easy picture to paint, and in general opening a tab instead of a window would increase the amount of effort it would take one to understand the complexity of the API, which would be important in this case. Also it was clear that tabs is the more important module of the two, so it would be better to promote that module.

tabs

There are a number of minor things that don’t work here, and we have bugs for.

Setting the tab.index like tab.index = 1 doesn’t work, it’s not yet possible to change the order of the tabs, bug 782461.
Pinning tabs is not possible, that is bug 782819, which means opening a pinned tab does not work either.
Finally, tab.favicon and tab.getThumbnail() both don’t work because they would need to be async methods, so bug 794320 is for tab.favicon and bug 791098 is for tab.getThumbnail(). I think these methods should be deprecated in favor of separate async module(s), but we’ll see.

Example: Tab Usage

Somewhere on the internet there is a video of Aza Raskin talking about a simple little Jetpack called “Tab Usage Statistics” if I recall correct. It was a simple demo for the Jetpack prototype, and since I needed a simple example for the tabs module that would work for Firefox and Fennec, I decided to rip the idea off :)

Sadly I could not just take and code and morph it for the sdk because I couldn’t find the epic source anywhere. So I moved forward and recreated it.

This add-on is called Tab Usage, it displays a graph of the number of tabs you have open over time. T0 starts when you open the graph. You open the graph via a button in the preferences for the add-on, because that was a place I could depend on for Fennec and Firefox.

The main.js file here is simple

var tabs = require("tabs");
var { setTimeout, clearTimeout } = require("timers");
var sp = require("simple-prefs");
var { data } = require("self");
var { PageMod } = require("page-mod");
var URL = data.url("page.html");

function updateTabCount() {
  this.port.emit("update", tabs.length);
}

The function above will send the total number of tabs to the graph with a "update" event.

sp.on("open-page", function() {
  tabs.open({
    url: URL,
    onReady: function(tab) {
      var mod = tab.attach({
        contentScriptFile: data.url("page.js"),
      });

      var update = updateTabCount.bind(mod);
      tabs.on("open", update);
      tabs.on("close", update);
      mod.on("detach", function() {
        tabs.removeListener("open", update);
        tabs.removeListener("close", update);
      });
      update();
    }
  });
});

This simple-prefs listener is waiting for the “Open” button to be pressed, at which point it opens a new tab for the graph, when that page has loaded a content script is attached to the page which will hear the "update" event mentioned above and do the graph updates.

Summary

I hope you enjoy! It should be pretty easy to make add-ons such as Tab Usage for Firefox on Android now. I have a few more add-ons in mind which will be using tabs and they will be coming out soon!

This change will be released with v1.12 of the Add-on SDK.