Porting a legacy add-on to WebExtensions

tl;dr: Search Keys has been ported successfully and it is known as Add Search Number. Please try it! It works with Google, Yahoo (HK/TW/US), Bing, DuckDuckGo and even Wikipedia’s search page.

188279

Add Search Number

I have been using the excellent Search Keys add-on (original page) for a long time. It allows one to “go to search results by pressing the number of the search”. However, it hasn’t been updated for the better half of a decade and most features (e.g. support for Yahoo! and Bing) had broken, except for the numbers for Google Search.

Recently, there has been a push to move to the WebExtensions API, especially since Firefox 57 will stop supporting legacy XUL add-ons. Hence, I set about a quest to see what it takes to port Search Keys away from XUL, and I kept the author updated throughout.

Discoveries:

  • Using GitHub with Travis and ESLint integration was crucial for saving myself time avoiding silly syntax errors. I’m sure it could be done in your favourite online repository hosting alternative (Bitbucket/GitLab), etc.
  • Getting web-ext via npm also proved essential, along with WebExtension examples
  • You need to check if the old APIs have equivalents.
    • Search Keys was using nsIIOService which had no equivalent, but it was only used for ensure that a URL is indeed an URL, so I just did it another way (new URL = “<url>”). Thanks :MattN for the tip.
    • Another usage was for openUILinkIn, and there are similar-enough WebExtensions equivalents for this (tabs, windows).
    • (File a bug if an equivalent isn’t available, but first check for dupes)
  • Migrating an old project by another person is hard. I had to have several commits where I removed features, wither down the code to the bare minimum (my objective was just to add numbers for Google Search results), got it to work, tested, and then re-added support for Yahoo!, Bing, and even DuckDuckGo and Wikipedia.
  • Comments proved extremely helpful, in the absence of documentation.

I took about 2 days to port the add-on. Developing an add-on now has come a long way and is now much easier due to the presence of these tools (GitHub, devtools, etc.) as well as AMO being much improved ever since I started writing my first add-on (ViewAbout) almost a decade ago. Sadly, ViewAbout will unlikely be ported to WebExtensions, if ever. (Reasons are at that link)

This was tested on Firefox 55, exactly experiencing the difficulties that an add-on developer currently would face right now.

The only major caveat?

There were times when I set a breakpoint on a content script using Firefox’s Developer Tools (instantiated via web-ext). After I refresh the page, the extension would occasionally “disappear” from the devtools. I would then have to close Firefox, restart it via web-ext, re-set the breakpoint, then cross my fingers and hope that the devtools will stop at the required breakpoint.

In my experience, this has been straightforward, as the original add-on was fairly simple. I understand that for other complex add-ons, the porting process is much more complicated and take a much longer time.

What has your experience been like?

(Please note that this post does not discuss the pros and cons of whether Firefox 57 and later should use WebExtensions or not, hence cutting off legacy support, any comments on this will be removed.)

Advertisements

Valgrind builds are now green on TBPL

Valgrind builds are now green on TBPL as of this morning!

I filed bug 800435 to get the build unhidden – previously it was hidden on tbpl.mozilla.org (TBPL) because it was always fiercely burning.

Note that the some of the multiple builds you see in the screenshot were manually triggered, otherwise only one per day is automatically scheduled.

What are Valgrind builds?

Running Firefox binaries with Valgrind helps to detect run-time memory management bugs, so it finds problems like use-after-frees (invalid reads/writes), uninitialized variables as well as memory leaks.

Note that the run-time speed of the application will take a substantial hit – it can take a long time to start up a Valgrind build. Moreover, a fairly powerful computer running Linux / Mac (preferably Linux) with about 4 GB memory is recommended. Tests are thus run once a day due to the slowdown, and we currently run only PGO tests (a small subset of our tests, note that our Valgrind builds are not PGO though).

How was this accomplished?

It is important to note that a lot of work by other folks was put in a year or two ago to get Valgrind showing up before it was hidden by default on TBPL for being perma-red. I then stepped up to help turn it green since I had some experience in running JavaScript binaries with Valgrind, and we all love greenery. 🙂

When I first embarked on this about 3-4 weeks ago, I found and helped to fixed 3 harness bugs, assisted in upgrading Valgrind twice, detected 35 potential issues at the time of writing (some of which were intended leaks), with 3 non-sensitive ones being fixed, some being recent regressions and one other being potentially security-sensitive. With the issues now known and filed as bugs, they were added to suppression files which also live in the mozilla-central tree. I also accidentally stumbled on a supposed TBPL selfserve bug that turned out to be a Firefox regression.

How can we help?

This is just a small step forward. In the future, ideally we should:

and we should also incorporate AddressSanitizer (Asan) builds into TBPL. (Asan is a faster memory error detector than Valgrind, and sometimes finds a different class of bugs, but it does not detect uninitialized values the way Valgrind does)

Christian Holler [:decoder] has some regular Asan builds but they are only run through the Try servers.

Anything else?

Shout-outs go out to the following people: Julian Seward, Nicholas Nethercote, Jesse Ruderman, Ted Mielczarek, Releng folks Chris AtLee, Nick Thomas and Rail Aliiev, our sheriffs edmorley, philor, RyanVM, and all others whom I have inadvertently left out. Without any of your collaboration and hard work we would be unable to have this set of Valgrind greenery. You folks rock!

Edit: Bug 800435 has been fixed, Valgrind builds now appear by default, thanks Ehsan! See the following screenshot:

Edit 2: It’s been re-hidden again because it’s “not a tier-1 platform“.

Bonus: Here’s a video showing the Endeavour Space Shuttle flypast in Mountain View. Just in case you haven’t seen it. 🙂