Tag: jetpack

Some of you might remember reading my blog post on my experience about porting the Bugzilla Tweaks jetpack to the Jetpack SDK.  I talked about almost everything in that post except where you can find the actual extension!  That was intentional, because there were quite a few bugs in the early versions, and I didn’t want to release something which is basically broken.  But those issues have been mostly solved now, and I’m releasing the jetpack as a Firefox extension.

You can find the extension’s home page here, or you can grab the extension directly from AMO.  Please note that this extension can be installed in Firefox nightly versions without having to restart the browser!  Also, please note that once you install this extension, you can safely uninstall the Jetpack Prototype extension (if you don’t use it for other purposes of course) as this extension is self-contained and does not depend on any other extensions.

The source code for this extension has been moved to my extensions repository.  The old source code respositry for the Jetpack Prototype based script is still available, but is not going to be maintained any more.  All future updates will be made to the new repository.  The source code is being released under the MPL/GPL/LGPL tri-license.

I’m eagerly looking for your feedback, especially if you can find something which is broken.  Please comment here or contact me directly!

Tagged with: , ,

Recently, I decided to convert my Bugzilla Tweaks jetpack to an extension based on the Jetpack SDK, which is still under development.  This post is meant to be a document of my experience with the Jetpack SDK for creating a real-world and useful extension for Firefox.

As the very first step, I needed to actually get the SDK set up and running.  So, I went straight to the Getting Started guide.  Here is how I set it up.  I cloned the hg repository (to make sure that the process of updaring my extension to future versions of the Jetpack SDK is as easy as just updating the repo and rebuilding the extension).  At this point, you can make a choice.  You may either want to stay on tip, or update to a release version (which may be a little more stable than tip — but remember that the Jetpack SDK is still under development).  I chose to update to 0.4, which is the latest released version as of this writing.

Then, I went ahead with . bin/activate and cfx testall, to make sure that I’ve get a working environment up and running.  I sat there and watched the command prompt waiting for the tests to be completed, but I got tired and pressed Ctrl+C to cancel the operation after about 5 minutes.  Then, I decided to run cfx testall –verbose to see what’s happening, but again, it just went yoohoo after running some tests.  I canceled again and decided to just assume that everything is working correctly, for lack of a better way to actually verify that.

Then I proceeded to read the Packages documentation.  I skimmed over it, and then proceeded to the Programs documentation.  That seemed to be interesting, so I read that more thoroughly.  It all seemed easy enough.  The only strange part was that I seemed to have to create my packages under the Jetpack SDK directory.  That seems less than ideal to me, but I decided to try to create a real directory for my extension somewhere, and just add a symlink to it under the packages directory.  That worked, which was nice.

After this point, I just copied the old bugzilla-tweaks.js file as lib/main.js, and started to figure out how to make the extension do something useful.  Before anything else, I’d need something equivalent to the Jetpack Prototype’s pageMods facility.  So, I grabbed Atul’s persistent-page-mods.js module, and started looking at it (he’d pointed me to it here).  Soon I figured out that I needed to have the dependencies of this package available as well.  I searched for "require" in that file, and found out that it depends on timer, errors and unload-2.  The only one not available in jetpack-core was the latter, so I grabbed it as well.  unload-2 itself didn’t have any dependencies besides unload, which ships in jetpack-core, so the dependency search was done.  One thing that I wish we had was a tool to recursively extract the dependencies from any given package.  Atul also told me that I needed the tab-browser package, but I noticed that it’s there in 0.4.

Then I stole this code to get the pageMods functionality hooked up.  This far into the process, I’m loving how easy it is to use other people’s packages and code in your new Jetpacks.  I think that’s going to blow away how people write extensions for Firefox and other Mozilla-based applications.

For the most part, the Bugzilla Tweaks jetpack is a bunch of DOM API calls, and I expected those parts to just work.  I only needed to port my Jetpack Prototype API usage over to Jetpack SDK APIs.  In addition to pageMods, I used jetpack.menu to add context menu items, and jetpack.clipboard to modify the clipboard.

The context-menu API documentation was straightforward, and I ported my usage of the jetpack.menu API to context-menu very quickly.  Porting jetpack.clipboard was a bit more involved, though, because jetpack-core does not include a clipboard module yet, so I had to write my own.

I decided to go with the JEP specification of the clipboard API, which has not been implemented yet.  This is a relatively simple API, providing three methods: get, set and getCurrentFlavors.  For this extension, I only needed the set method, so that’s what I implemented for now.

I also had two direct XPCOM call sites in my original Jetpack, one for reading a preference, and the other for reading a cookie.  Jetpack SDK comes with a preferences-service package, so I decided to use it.  I also created a small cookiemanager package and switched to using it.  The benefit of this is that if in the future, the Jetpack SDK does not allow direct usage of XPCOM components, I can just modify one package.  Also, I can use the package in my other projects, and so can others!

Now was the time to try the extension for the first time!  Before generating the XPI, I added a few more fields to the package.json manifest, and then I ran cfx xpi.  It told me that I needed to remove the id field from the manifest, which I did.  The next time I ran cfx xpi, it told me that the manifest is updated, and I need to run the cfx xpi again.  This was kind of strange, and less than ideal (why didn’t the tool do what’s needed on its own?).  Anyway, I re-ran cfx xpi, and finally I had an XPI, waiting to be tested.

But before testing, I was curious to see for myself what the generated XPI contains.  So, I unzipped the package, and started looking around.  The generated install.rdf contained entries for Firefox, Fennec and Thunderbird.  I found that strange.  I was never asked which applications this extension is compatible with.  I’m pretty sure that it won’t be compatible with Thunderbird, and I don’t even know what will happen if I try to install the XPI on Fennec.  And if the goal is for the extension to be compatible on all Mozilla-based applications, it should be a toolkit extension, right?

I also noticed that the install.rdf contains a bootstrap element, which means that the extension can be installed without Firefox being restarted if you use a trunk version.  Nifty!

Then, there was the resources directory, which contained a copy of all the Jetpack packages, both in bugzillatweaks, and in jetpack-core.  What I found really broken was that .main.js.swp, which is the Vim swap file which was around because I had main.js open in Vim made its way to the XPI package.  Not so nice.

There was also a components directory, containing a harness.js file, which I didn’t look at very carefully.

So, I went ahead and opened up a development profile that I had set up to develop and test the old version of the jetpack in Firefox 3.6.  I disabled the original jetpack, dropped the XPI into Firefox, and restarted.  Lo, and behold!  I had my extension installed, but it didn’t work!  There was no error logged to the error console, and no possible way to tell what was going wrong.  I felt clueless as how to proceed.  I decided that having Jetpack Prototype installed might be conflicting with something, so I disabled that extension and restarted.  Still no luck.

So, I went ahead and added a bunch of console.log calls in the beginning of the main function, to see if it’s called, but apparently it wasn’t.  I decided to give things a shot with a nightly.  So, I launched a nightly Firefox from the console, and boy was I lucky to have done that!  I got this error on the console (that is, the OS X Terminal application):

error: An exception occurred.
Traceback (most recent call last):
  File "resource://jid0-qbniplfdfa4lpdrjhac6vbqn20q-bugzillatweaks-lib/main.js", line 340, in null
SyntaxError: syntax error

OK, that explains a lot.  But I found this out completely out of luck.  The SDK really needs to expose such errors in a more discoverable way.

So, I went ahead and fixed the syntax error, re-generated the XPI, and opened it in Firefox.  Because it’s a rebootless add-on, it didn’t require the browser to restart, and I got "info: main" on the console (again, the OS X Terminal application), which was the debugging message I had added to my main function, so the jetpack was correctly loaded!  

But apparently I have to watch the Terminal window instead of Firefox’s error console, which sucks.

From there on, I spent some time debugging using console.log calls, and finally I managed to have a working Jetpack.

The entire process was rather pleasant.  I hit a few bumps along the road, as I explained above, but hopefully others will read this post and know how to avoid them while the amazing guys in the Jetpack SDK team fix those issues.

Tagged with: , , ,

Atul Varma has built an user name autocomplete tool for Bugzilla.  This reminded me that it’s been a long time since I wanted to add this functionality to the Bugzilla Tweaks jetpack.  Last week I added this feature, but I didn’t get the time to blog about it!

Here is how it looks on a a sample bug:

User name autocomplete for the Assignee field

It is also smart enough to handle multiple users for fields which accept it.

User name autocomplete for multiple users

It works on almost everywhere in Bugzilla where you can enter a user name.  Here is the full list for the curious:

  • CC field on bug pages (both when viewing and filing a new bug)
  • Assignee field on bug pages (both when viewing and filing a new bug)
  • Requestee field on attachments (when you request a flag, like review, from someone)
  • User name entry fields on the advanced search page
  • Add user watch field on the preferences page

This is providing the same functionality of Atul’s tool, with two added benefits: it provides the functionality right where you need it, and doesn’t require you to enter your user name and password.

No more memorizing people’s email addresses!  No more asking around for their email addresses!  No more bugzilla error pages telling you that the user name you entered doesn’t exist, or couldn’t be matched exactly!  I hope you like the idea.

The jetpack lives here.  If you have already installed it, you can either rely on Jetpack Prototype’s auto-update feature, or refresh it manually.

Tagged with: , ,

If you use Firefox nightly builds, and you had the Jetpack Prototype installed, you might have noticed that about two weeks ago, your jetpacks had started to get disabled a short while after you had opened your browser.  This issue was really frustrating, since some of us run jetpacks which are very important in our daily work.

I filed bug 554169 about this issue.  Paul O’Shannessy fixed this, and earlier this week, the Jetpack team released a new version of the Jetpack Prototype which fixes this issue.  You can install it from AMO, and your jetpacks will resume working reliably on nightly builds.

Thanks a lot to Paul, Myk and Atul for making this happen!

Tagged with: , ,

Bugzilla is an essential tool to the working process of Mozilla, and many of us spend a good portion of their day in Bugzilla.  The Bugzilla Tweaks jetpack is an attempt of me and Johnathan to make this process more efficient and productive.  If you have never heard about it, it would be a good idea to first read Johnath’s original post and then my previous one.

Since I published the original enhanced version of the Bugzilla Tweaks jetpack, I have received a lot of positive feedback.  Max Kanat-Alexander event suggested that he likes the UI so much that he’s going to consider using it when the feature is ported to Bugzilla itself.  Several other people have also suggested things that they would like to have in their every day usage of Bugzilla.  I’ve been implementing all of these features and adding even more new features and fixes to the Jetpack.  I thought that the volume of changes has been large enough to deserve another post, so here we go!

Attachment flags with links pointing to the time when the flag was set

Did you ever wonder at which point a flag on an attachment was set, and what the context was?  Wonder no more!  Bugzilla Tweaks now linkifies the attachment flags to point to the exact location where the flag was set.  No matter whether it’s a review, superreview, ui-review, approval, or any other type of flag, merely clicking on the flag name takes you to the exact location where it was set and you can see the exact context right away.

Attachment numbers linkified with names in their tooltip

Now, the attachment numbers generated by Bugzilla Tweaks in history events are links which point to the attachment edit page.  The name of the attachment appears as the tooltip for that link.

Bug dependencies linked to the respective bugs

Bug dependency changes are now linked to their respective bugs.  The title and status of the bug also appears as a tooltip for those links.

URLs appearing as links

Comment numbers appearing as links

We are used to the fact that things like URLs, bug numbers and comment numbers are linked in Bugzilla.  To keep this convention so that Bugzilla Tweaks is as good a citizen in Bugzilla as possible, I’ve made it convert all of those to links as well.

Duplicate markers appearing as history events

We all have seen comments with this content too many times in different bugs:

*** Bug 123456 has been marked as a duplicate of this bug. ***

This is an automatic comment which Bugzilla puts in a bug when another bug is marked as a duplicate of it.  Nearly most of this comment is just noise, and it’s really part of a bug history, not a real comment.  So, Bugzilla Tweaks converts them to history events, so that you don’t confuse them with actual comments.  There is one interesting point here.  Since Bugzilla shows these as comments, they have a comment number and can be linked to by adding #cNN after the bug’s URL, where NN is the number of the comment.  In order to keep those URLs working, I made them point to the history events instead of the comment which no longer exists.

To get the latest version of the Jetpack, you can either install it from this page if you don’t already have it, go to about:jetpack and refresh the installed version of the Jetpack, or simply wait until the Jetpack engine updates it automatically from the server in the background.

Feel free to suggest any other interesting things which you would want in this Jetpack.  So far, every feature that others have requested from me has been implemented, so there is a good chance that yours would be as well!

Tagged with: , ,

A while ago, Johnath unleashed the Bugzilla Tweaks jetpack, which implemented Beltzner‘s original idea.  This jetpack adds the information regarding the history of a bug in a right-hand column on bug pages.  I liked it a lot, but I thought that it could be even better, and now I am releasing a tweaked version of that jetpack.

Let’s see what this Jetpack does in action.  The below screenshot shows a change made to a bug while adding a comment.

Changes with a comment

Here, you can see that the status of the bug was changed from NEW to ASSIGNED, and the bug was assigned to dmandelin.

If the change was made without any comment on the bug, an entry is added between the two comments, with an indentation, which hopefully makes it easy for the eye to detect this entry subconciously.

Changes without a comment

Here, you can see that dvander has reviewed a patch, and has marked it r+.  If you want to know exactly when this change has been made, you can just move the mouse pointer over the name of the person who has made the change, and a tooltip shows the time that change was made.

The changes on each bug are shown interleaved with comments as above, with the exception of CC changes.  CC changes are usually not interesting, and they tend to add more clutter than useful information to the history of the bug.  If you want to view the CC history though, you are not out of luck, you can just right-click on the page and choose Show CC History, and all the CC changes will appear.  You can toggle them off by righ-clicking on the page and choosing Hide CC History.

Showing the CC history

CC history displayed

You can see that several CC changes which had occurred between two comments have appeared.  Please note that the CC history visibility setting is not persisted, and each time a bug page is loaded, it will default to hiding the CC history.

Also, in the above screenshot you can see that if the person making the change has commented on the bug as well, their actual name is displayed, otherwise, only the email address will be displayed.

Another feature which is probably useful for drivers and those who triage bugs (among others) is that if a flag has changed during the lifetime of the bug, its name will be converted into a link, and clicking on it will take you to the latest change on the flag.  This both works for real Bugzilla flags and the "pseudo-flags" that we have been using for branch management lately.

Easy access links to the latest change on a flag

To grab it while it’s hot, make sure that you have the Jetpack engine installed.  If you have, when you visit this blog post, you should get a prompt that this page contains a Jetpack.  Just click the Install button and you’re all set.

The source code for this jetpack lives in Johnath’s user repository.  Suggestions, bug reports, and patches appreciated!

Tagged with: , ,