Posted by: Raffaele Spinelli | January 29, 2018

Another painless conversion from JPM to WebExtension

This week I had enough time to play around with an addon I made some time ago. JSONDiff is an addon to easily compare JSON documents, and its source code can be found on GitHub.

The latest version was based on JPM, so I decided to port it to WebExtension. Good for me, the addon is an easy one, it only relied on the tab API from the SDK. Thus, its porting from JPM to WebExtension was utterly painless.

I had few things to do:

  1. Create a proper manifest.json file
  2. Adapt the used APIs to the available ones in WebExtension
  3. Check the addon on the new Firefox
  4. Adapt the tests for a different framework (optional)

Manifest file

Mozilla has done a great job in improving both its code and the documentation. I am particularly happy with the WebExtension documentation that is now quite comprehensive.
The perfect entry point is this guide on how to get started with WebExtension or the walkthrough of your first addon. Of course, the next step is to go through the API documentation.

Adapting APIs

If you are lucky, like in my case, all the JPM APIs your addon uses are available in WebExtension as well. You just need to adapt your code to the new ones and that will be all.
In my case, I only have to adopt the tabs APIs.

WebExtension cli

Mozilla offers a command line tool to help people to build, run and test WebExtension addons. The web-ext cli can be easily installed through npm. Make sure to follow the instructions on and read the documentation. I like this tool very much cause it helps you to try your addon for different versions of Firefox, even Firefox Android.

Unfortunately, running tests with this tool is a matter of open discussion at the time of writing this article.


For my addon, I chose to employ at least unit testing. At the time, I chose to rely on the JPM cli to run the tests but there is no equivalent in the web-ext cli.
After a couple of hours spent googling for JavaScript testing framework I came up with an idea to test my addon, thanks also to the suggestions discussed on the web-ext GitHub project.

My setup includes:

  • Karma – Test runner
  • Mocha – Test framework
  • Chai – Assertion library for TDD and BDD

Get familiar with these tools if you really want to properly understand how to do testing in JS.

NOTE: I used Chai to achieve objects deep comparison.

In my karma-config.js file I specified the frameworks I want to load

> frameworks: ['mocha', 'sinon-chai'],

I also specified which files to load:

> files: [ 
> // Source 
> 'data/js/*.js', 
> // Tests 
> 'tests/*.js' 
> ],

A test snippet may look like this:

> describe('jsondiff', function() {
>   describe('isArray', function() {
>     it('It should be false if not an array', function(done) {
>       expect(jsondiff.isArray(false)).to.equal(false);
>       done();
>     });
>   });
>  ....
> });

If the configuration is ok, you can run your tests with the command npm test.

Take a look at the JSONDiff repository for a complete example and CI (Travis) integration.

Posted by: Raffaele Spinelli | November 2, 2017

Gentoo, systemd and wpa_supplicant

Recently I switched from openRC to systemd. It was a tough choice, but beside the many, many discussion that took place over the years, I decided to give it a try.


So, here we are trying to do the transition. I followed the detailed guide provided by Gentoo on how to install systemd. After I finally rebooted, everything was working as expected, beside one little, small, annoying thing: the boot was taking 90 seconds.

So I inspected the log and find out the following messages during the boot:

A start job is running for sys-subsystem-net-devices-multi-user.device


Apparently the service wpa_supplicant@wlo1.service was not enough. Something was using a multi-user device.
With a little help from my friend grep I found out the culprit.

grep -RHn multi /etc/systemd/
> /etc/systemd/system/

While the aforementioned file was referring to the multi-user device, the file /etc/systemd/system/ looked good.


I hardcoded the interface in the mentioned file, in vim you can simply do :%s/%i/wlo1/g and at the next reboot, the boot was quick as one would expect.
Probably making the wpa_supplicant@.service a symlink to wpa_supplicant@wlo1.service would have sufficed as well.

NOTE: I only had wpa_supplicant@wlo1.service enabled with systemctl enable wpa_supplicant@wlo1.service.




Posted by: Raffaele Spinelli | September 19, 2016

Gentoo on Spectre x360

A couple of weeks ago, my laptop, a 4 years old ultrabook, stopped working because of a bus problem. Instead of asking the manufacturer to fix it, I took the decision of buying a new laptop.

At the end of some research (and some misadventures with another manufacter) , I opted for a HP Spectre x360 4110nl. It is a gorgeous machine.

First things, first. I disabled the safe boot and booted the Gentoo Live DVD. Everything was working  out of the box, even the touchscreen.

So I installed it from stage3, but I did not compiled my own kernel. Instead, I used genkernel. It was my first time with genkernel, I usually compile it manually.


Here is the list of hardware and the output of lspci

Device Hardware Status Module
Processor Intel i5 (sixt gen) 6200U
Video Intel HD 520 Working, see tweaksi intel i915
Wireless Intel Corporation Wireless 7265 Working iwlwifi
Bluetooth Unknown Unknown ?
Audio Intel Working snd_hda_intel
Touchpad SynPS/2 Synaptics TouchPad Working ?
TouchScreen ELAN Working, see tweaks ?
Webcam ? Working ?
Card Reader ? Unknown ?
USB Working xhci_pci
Function/Multimedia Keys Working ?


00:00.0 Host bridge: Intel Corporation Sky Lake Host Bridge/DRAM Registers (rev 08)
00:02.0 VGA compatible controller: Intel Corporation Sky Lake Integrated Graphics (rev 07)
00:13.0 Non-VGA unclassified device: Intel Corporation Device 9d35 (rev 21)
00:14.0 USB controller: Intel Corporation Device 9d2f (rev 21)
00:14.2 Signal processing controller: Intel Corporation Device 9d31 (rev 21)
00:16.0 Communication controller: Intel Corporation Device 9d3a (rev 21)
00:17.0 SATA controller: Intel Corporation Device 9d03 (rev 21)
00:1c.0 PCI bridge: Intel Corporation Device 9d10 (rev f1)
00:1c.1 PCI bridge: Intel Corporation Device 9d11 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Device 9d48 (rev 21)
00:1f.2 Memory controller: Intel Corporation Device 9d21 (rev 21)
00:1f.3 Audio device: Intel Corporation Device 9d70 (rev 21)
00:1f.4 SMBus: Intel Corporation Device 9d23 (rev 21)
01:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5227 PCI Express Card Reader (rev 01)
02:00.0 Network controller: Intel Corporation Wireless 7265 (rev 61)



To correctly use the video card you need to include the firmware into the kernel. Look at the Wiki page about Intel.For this model I needed to add

CONFIG_EXTRA_FIRMWARE=”i915/skl_dmc_ver1.bin i915/skl_guc_ver4.bin”


Worked out of the box. Just remember to add the wpa_supplicant service to rc.


To enable to touchscreen I needed to re-compile the kernel with CONFIG_HID_MULTITOUCH.

There are still some feature missing, that I need to sort out:

  • Double tap
  • Auto rotation adjustment
  • Disabling keyboard when in tablet mode
  • OS virtual keyboard


Posted by: Raffaele Spinelli | September 20, 2015

Developing and testing Mozilla Add-on – part 2

In this article we will see how we can use a CI infrastructure like Travis in our add-on development process.
Before you proceed you should get familiar with how Travis work. You can find the relevant documentation here.

Before we can run our script for testing, we need to setup Firefox.
We will use the before_script section to download and install Firefox. We will use npm.

- npm install
- npm install -g jpm
- npm install -g mozilla-download

The script section, instead, will look like this:

- jpm test -v
Unfortunately we need something more. We need to specify the path of the Firefox binary.
The whole travis.yml file will look like:
language: node_js
  - "0.12"
  - DISPLAY=:99.0
  - TMP_DIR=/tmp
- sh -e /etc/init.d/xvfb start
- npm install
- npm install -g jpm
- npm install -g mozilla-download
- pwd
- cd $TMP_DIR
- mozilla-download --branch mozilla-central --product firefox $TMP_DIR
- export JPM_FIREFOX_BINARY=$TMP_DIR/firefox/firefox
- jpm test -v -b $JPM_FIREFOX_BINARY
    on_failure: never

Some further details:

The env section define three variables:

  • DISPLAY for the X server
  • TMP_DIR the directory in which we download Firefox
  • JPM_FIREFOX_BINARY the Firefox binary command

The before_script will install the necessary tool to download Firefox, it will install it and set the ENV variable JPM_FIREFOX_BINARY to the right path.

Finally the script section can run the test:

jpm test -v -b $JPM_FIREFOX_BINARY

I hope this can be useful, please feel free to contribute.
More post about add-on development are coming. Stay tuned.

Posted by: Raffaele Spinelli | September 8, 2015

Developing and testing Mozilla Add-on – part 1

Developing add-on for Mozilla is quite easy but testing every single changes made to the code can became tedious.

The usual process would be:

  • made a change
  • create the xpi
  • load Firefox
  • install the add-on in Firefox
  • test it

Have you ever wondered if you can simplify this process? The answer is “Yes! Of course.”
The idea is to automate the packaging and the installation of the add-on at every change it’s made.

Firstly, we need to know a little more about the Mozilla add-on SDK and its tool.
The latest tool made available by Mozilla to develop add-on is called jpm and it shows a very interesting command

– watchpost: It create a new xpi everytime a change is made to the add-on files and post the fresh xpi to a specified URL. More details can be found on Mozilla jpm page.

FUrther, thanks to Wladimir Palant, we can use an add-on that can help us to simplify this process.  It allows you to install/update an add-on by command line, using web-socket.
Download and install this add-on, you can find more information about the configuration here.

Now that we have a convenient way of installing/upgrading an add-on, we can take advantage of the jpm `watchpost` command.
We can now simply run the following command in our add-on directory:

jpm watchpost –post-url http://localhost:8888/

You can see a simple log for this command on my machine:

JPM [info] Starting jpm watchpost on <ADD-ON NAME>
Creating XPI
JPM [info] XPI created at <XPI-PATH> (249ms)
Created XPI at<XPI-PATH>
Successfully created xpi at<XPI-PATH>
Posted XPI to http://localhost:8888/
Removed XPI from<XPI-PATH>

Our process to test the add-on now is:

  • load Firefox
  • made a change to our add-on (the watchpost command will take care to upload the add-on to Firefox)
  • test it

I hope this can be useful, please feel free to contribute.
Next part will be about CI in add-on development using travis and github.

Posted by: Raffaele Spinelli | April 24, 2014

Studying GraphWalker

Last week, I decide it was time to change my way of testing Web Applications. Recently, I have heard of graphwalker, that seems to be a powerful tool so I decide to give it a try.
I really like to always have the latest version, so I checkout the latest version of code from their server.

git clone

But Maven fails to build the project when I run mvn test.
The error is raised because of a missing jar:

If you incur in this error, you just have to fire up your preferred editor and edit the pom file.
Just add these repository to download the missing jar.

      <url> </url>

Rerun Maven and everything should be fine.
A modified version containing the repository is available here: pom.xml
Next weekend I’ll try to write down some example too.