Category Archives: Mozilla

Day 2 at Mozilla Messaging: pbranch, testing, teleconferencing, intranet, and more testing

Ok, today was my second day at Mozilla Messaging.  Another good day.  Here are some highlights:

Today, I started off my day by wanting to learn a few things:

  1. How to use pbranch to locally commit my Firefox patch from yesterday
  2. How to write tests for my patch using Mochitest

I started with the first one.

So, for the most part, Mozilla uses Mercurial as its distributed version control system.  I’ve been using Git (arguably Mercurial’s main competitor) since last summer with both MarkUs and Review Board.  Mercurial is something quite different.  Quite different indeed.

pbranch is a tool that lets me have a patch queue.  Basically, organization, and re-organization of any changes I make to the Mozilla code-base is a lot easier using something like pbranch.

So I spent a few minutes going through the pbranch tutorial.  Eventually, I think I got the hang of it – basically, for my extension changes-sets, I create a new branch using hg pnew, and commit to that branch.  I’ll keep committing to that, and when I’m all done, I’ll dump my patch to a Bugzilla attachment.  After I pass code review, someone will merge my patch.  Then I’ll remove my local branch and pull in my changes.  Sweet!

Ok, so at this point, I think I got the workflow.  Next, I needed to figure out how to write a Mochitest.  Thankfully, there’s this tutorial.

Looking through the documentation, I was reminded of Selenium a little bit.  I think it’s sort of the same idea.

So how do I write a test for my changes?  Unfortunately, the documentation on how to write a Mochitest is a little thin.  So I started hunting around, looking for examples to extrapolate from.

At some point, I found myself staring at this code.  Wow!  A full-blown API for manipulating the add-ons manager!  Great!  But it turns out that this is for Mozmill tests, and not Mochitests.  But a quick search through MXR showed that nobody was using that add-on manager API.  Argh.

Was I barking up the wrong tree here?  Where the hell were the add-on manager tests?

I quickly swallowed my pride, and decided to talk to an expert.  I used Mercurial’s log function to determine who had changed extensions.js the most.  The name Dave Townsend came up.  According to his site, he’s “Mossop” on IRC, but he wasn’t online.  The log function also mentioned the name Blair McBride.  On IRC, he’s “Unfocused”.  He was online, but unavailable.

Argh.

It was at this point that Blake told me that the Mozilla Messaging weekly meeting was going to take place.  Apparently this happens every Tuesday at 9:30AM PST.  So we marched over to a conference room, hooked up this super-advanced phone (the phone had a boot-up screen, and then showed the Mozilla logo…whoa!).  A little while later, the meeting began.  The meeting was super fast, and super efficient – especially considering the teams are spread out across the globe.  One person led the meeting, and called the different teams up to give their weekly status.  I also got to introduce myself to the team.  I rambled off something about Thunderbird+Unity and code review, and then stumbled back to my chair.  Cool times.  Anyhow, teleconferencing is going to take some getting used to.

So, with the meeting over, and still no word from Unfocused, I decided to clean up my code a bit, and then posted my patch up on Bugzilla.  I asked Dave Townsend for a code review, and said that if testing needs to happen, hopefully he’d let me know and advise me.

It didn’t take long for a response to come back.  Apparently, there are indeed tests for the add-ons manager, and they’re right here in front of my face.  Crap, I should have known.  :/

So I dove into those tests…wow, there were a lot of them.  And I didn’t have a clue as to how to run any of them.

Following the Mochitest instructions, I eventually tried this:

TEST_PATH=toolkit/mozapps/extensions/test/ make -C $OBJDIR mochitest-plain

(where the TEST_PATH is set to the folder of tests I want to run, and $OBJDIR is an environment variable that points to the objdir compilation folder for Firefox.)

But this only ran a single test out of the bunch, and there were hundreds in there.  So what was the deal?

It turned out that the tests I wanted to run were with higher privileges than your average Mochitest test.  A basic Mochitest test is run using mochitest-plain.  Apparently, I needed to use mochitest-browser-chrome.  Took me a good half-hour to figure that one out.  :/

Anyhow, BAM, I had it – the tests were running.  The bad news:  I had a bunch of failing tests.  The good news:  the same tests failed without any of my changes.  So…great…I guess.

It was at this point in the day that I was given access to the Mozilla Messaging Intranet (the internal wiki).  There was plenty to read there, including something along the lines of “So you’re a new Mozilla Messaging hire”…I gave that a read.  Very interesting.

After that, I subscribed to a few internal mailing lists, and submitted my Mozilla-centric blog feed to be added to Planet Mozilla and Planet Mozilla Messaging.  Woop!

Finally, I got back to testing.  After digging through those add-ons manager tests, I finally found this:  PAYDIRT.

Sweet!  Tons of stuff for free in there:  MockProvider, createAddons… writing tests in there looked like it’d be cake.

But then it was home time.  More tomorrow.

Today, I want to learn a few things:

  1. How to use pbranch to locally commit my Firefox patch from last night
  2. How to write tests for my patch using Mochitest

Lets start with 1:

So Mozilla uses Mercurial as its distributed version control system.  I’ve been using Git since last summer with both MarkUs and Review Board.  Mercurial is something quite different.

Started going through pbranch tutorial.

So for my extension changes, here’s what I’m going to do.  I create a new branch using pnew, and commit to that.  I’ll keep committing to that.  When I’m all done, dump my patch to a Bugzilla attachment.  Someone will merge my patch.  Then I’ll remove my local branch and pull in my changes.  Sweet!

Ok, so I’ve got the workflow (I think).  Next, I need to figure out how to write a Mochitest.  Thankfully, there’s this:  https://developer.mozilla.org/en/Mochitest

I’m reminded of Selenium a little bit.  I think it’s sort of the same idea.

So how do I write a test for my changes?  Unfortunately, the documentation on how to write a Mochitest is a little thin.  So I guess I’ll be looking at examples, and extrapolating from there.  Let’s see if I can find a similar test written elsewhere.

This is promising:  http://mxr.mozilla.org/mozilla-central/source/testing/mozmill/tests/shared-modules/testAddonsAPI.js

Hm…but this is for Mozmill, and not Mochitest.

Yep, Mozilla uses a lot of different testing frameworks.  It’s a little confusing.  Mozmill is also like Selenium

So who is using testAddonsAPI.js?  Argh.  It looks like nobody.

I’m having a hard time finding tests for any of the stuff in extensions.js.  So I guess it’s time to talk to the expert.  I use hg log to see who the most frequent committer is to extensions.js.  The name Dave Townsend comes up.  http://www.oxymoronical.com/ .  He’s Mossop on IRC, and not online.  So who else is listed in hg log?  Blair McBride.

Had my first Mozilla Messaging weekly meeting.  It’s on a phone.  Interesting how its organized…really not like any phone conversation I’ve been a part of.  People mute themselves…unmute when its time to talk.  Awkward pauses are rampant…pretty cool though.  Coordinating around the world.  Nice!

Ok, back to Blair McBride…after a little hunting around, it turns out his IRC nickname is Unfocused.  I’ve found him in a few of the Mozilla IRC channels, and am waiting to hear back from him.

No word.  So, after some scrubbing, I posted my patch up on Bugzilla, and asked Dave Townsend for a review.  If testing needs to happen, hopefully he’ll let me know and advise me.

Whoop, just got a message.  The tests are here:  http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/test/.  Crap, I should have known.  :/

Ok, lets examine those tests… hold up.  How do I run these?  Trying to run that directory with Mochitest, I only get 1 test to run…wtf?

Success!  TEST_PATH=toolkit/mozapps/extensions/test/ make -C . mochitest-browser-chrome

Sweet, so all those tests run.  Bad news though – a bunch of failing tests.  Going to see if it was my patch.  Ok, looks like a bunch of tests were failing before I even committed anything.  That’s good, I guess.

So, I have to compare them in order to ensure that there aren’t MORE failing tests after my patch goes in.

I now have access to the Intranet.  Sweet – lots of stuff to read here.  “So you’re a new Mozilla Messaging hire…”

Just subscribed to a few internal mailing lists, and submitted by Mozilla feed to be added to Planet Mozilla and Planet Mozilla Messaging.  Woop!

Ok, back to testing, I’ve found this:  http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/test/browser/browser_sorting.js  This looks like paydirt.

The CEO of Mozilla Messaging (David Ascher) just welcomed me to MoMo:

mconley: welcome to the madhouse

Awesome. [WELCOME TO THE JUNGLE]

Sweet!  Tons of stuff for free:  MockProvider, createAddons – I think this’ll be cake tomorrow.

Ooops – Dave Townsend just asked a good question:  what about extensions that are to-be-installed?  to-be-uninstalled?  Where do they go?

I’ll have to check that out tomorrow.

But right now, it’s home time.

Day 1 at Mozilla Messaging: Getting my hands dirty…

So today was my first day working for Mozilla Messaging.

And it was awesome.

Now, I know that I had originally told you that I’d be working on Thunderbird + Unity integration.  That’s still on my TODO list, but today, I put some contributions in with the Firefox team for the upcoming Firefox 4 release.  There are still a few bugs that need to be squashed before Firefox 4 is ready for the prime-time, and we’re all psyched to see it happen, so I lent a hand.

This was the bug I decided to tackle today. Basically, in the new add-ons manager, add-ons are listed alphabetically, regardless of their state (and by state, I mean enabled, disabled, incompatible, blocked, etc).  This leads to kind of a strip-ey look for large numbers of add-ons.

What we’d like instead is to have the add-ons grouped by state, and then sorted alphabetically within that state.  Here’s a mock-up by bug-reporter (and Firefox UX team member) Jennifer Boriss:

Add-ons in list, grouped by status

I got to work around 8:45AM this morning.  Around 10:13AM, I had finished most of my introductions, had my tour, had my accounts set up, found my desk, and started work.

The first thing I did was locate where exactly the code was for listing the add-ons.  Blake pointed out a particularly useful resource called MXR (Mozilla Cross Reference), which lets me search through the source code very quickly.  I had originally been using grep, but this was way better.

My approach to finding the code:  I find a string in the interface that seems unique to the area I’m working in (in this case, it was “Search all add-ons”, which is found in the search text input of the add-ons manager).  I did a search for that string, and it returned the file mozilla-central/toolkit/locales/en-US/chrome/mozapps/extensions/extensions.dtd.

But this only takes us half-way.  Since Firefox is translated, the strings are stored separately from where they’re used.  In extensions.dtd, the string I searched for is given the key “search.placeholder”.

Searching for “search.placeholder” with MXR gives me paydirt:  mozilla-central/toolkit/mozapps/extensions/content/ holds the files extensions.css, extensions.js, extensions.xul and extensions.xml.

So I tool around in extensions.js a bit, reading the developer documentation, and getting to know the code.  The code contains quite a few classes, including something called gViewController.  Digging deeper into it, it looks like gViewController controls (brings up, shuts down) the various “views” available in the add-ons manager.  Cool – so now I just need to find the view that lists the user’s add-ons.

Ah hah!  Found it:  gListView.  gListView grabs all of the installed (or to-be-installed) add-ons, and populates the interface.  So this is where the sorting needs to happen.  I tested to make sure I was in the right place in the code by using dump calls to a terminal.  Bonus:  edits in this portion of the code do not require a full browser restart – instead, I just close and reopen the add-ons manager to see my changes.  Nice!

Initially, my idea was to have 4 “buckets”, one for each of the 4 states (“enabled”, “incompatible”, “disabled”, “blocked”).  I’d divide up the add-ons into those 4 buckets, and then sort each bucket, and then join the 4 buckets for the final result.

Blake came up with a better solution: the Schwartzian Transform (straight out of Space Balls, I know).  The idea is that, instead of having separate buckets like before, we just go through the entire collection of add-ons, and “label” them based on what bucket they belong to.  Then we sort the entire collection, giving the bucket-label a high-order sorting priority.  It sounds complicated, but it actually wasn’t that difficult to code.  It’s a tiny piece of code, its readable, and quite elegant.  So kudos to Blake for that solution.

Anyhow, I wrote my patch.  I just figured out how to run the interface tests for Firefox (they use something called Mochitest).  I set those tests off on one of the fast machines in the office, packed up my gear, and headed home.

It was a solid days work.  Tomorrow, I hope to write some new tests for the Schwartzian transform, and submit my patch to Bugzilla.  Woop!

Starting Work on Mozilla Thunderbird

With the Winter holidays drawing to a close, I’m really looking forward to starting the next chapter of my life – namely, my new job at Mozilla Messaging working on the Thunderbird e-mail client.

In just a little under a week, I’ll be knee-deep in a code-base larger than any I’ve ever worked on before.  And I’ll be working with some of the best software developers in the world.

I’m pretty stoked.

So, what exactly will I be doing for Thunderbird?  What project will I be starting my work with?  I’m so glad you asked…

Thunderbird + Unity = Badass

Ok, that’s not technically the code-name for the project, but I think it more or less conveys my feelings about the whole thing.

So here’s the story in a nutshell:

Ubuntu Linux is one of several operating systems that Thunderbird runs on (the other big ones being Mac OSX and the various flavours of Microsoft Windows).  I use Ubuntu as my primary operating system – I’m comfortable with it, and I like it.

In the coming months, there will be a tectonic shift of sorts in Ubuntu.  The graphical user interface that most Ubuntu users are used to (the GNOME Shell) will no longer be the default.  Instead, Canonical, the makers of Ubuntu, have created their own user interface to run on top of GNOME.  That interface is called Unity, and will be made default in the Natty Narwhal release (due to come out on or around April 28th of this year).

Just to make sure we’re clear on this:  Ubuntu is not dropping GNOME.  The GNOME Shell is the icing on the whole GNOME Stack.  Canonical has just decided to put their own icing on the cake.

So, anyhow, my job is to make Thunderbird work nicely with Unity in time for the April 28th release.

And by “work nicely”, I mean the following:

The Global Menu Bar

If you’ve never used Mac OSX, it’s likely that you don’t know what a global menu bar is.  Here’s the idea:  in Windows and Ubuntu, each window tends to have its own menu bar (File, Edit, etc…).

In Mac OSX, and the upcoming Unity shell, instead of having these individual menu bars, we have a single, overarching menu bar. This menu bar changes itself every time you switch application focus.

Here’s some guy demonstrating the global menu in Ubuntu Linux:

Currently, Thunderbird doesn’t “play nice” with Unity’s global menu bar, and just displays the menu within the Thunderbird window as it always has.

My job is to get Thunderbird to use the global menu bar properly.  Click here to read more about Ubuntu Unity’s global menu bar.

The Messaging Menu

Ubuntu Unity also sports a shiny new messaging menu.  The messaging menu aggregates all sorts of message-related information – and that includes e-mail messages, chat messages, social networking messages, etc.  It tosses all of these into a nice, clean, simple notification interface, like this:

Ubuntu Unity Messaging Menu

It’s up to messaging application developers to leverage this feature in Unity, and that’s where I come in.  I’ll be getting Thunderbird to work nicely with this messaging menu.  Click here to read more about Ubuntu Unity’s messaging menu.

The Task List

Ubuntu Unity also sports a new application launcher.  The launcher is a panel that stretches down the left-hand side of the screen, and allows users to quickly find and execute their applications.  It also lets users know which applications are already open.  In a way, it is very similar to the Mac OSX dock.

Here is a Canonical designer demonstrating the new launcher:

Unity Launcher Introduction from Canonical Design on Vimeo.

Right-clicking on an item in the launcher brings up a context-menu for the selected application.  For Thunderbird, we’ll probably want the context menu to allow users to do some common operations, such as fetching mail, and composing a new message.  We’ll probably also want to display the number of unread messages.  So that’s what I’m going to be looking into there.

I’m looking forward to tackling these problems!  I’ll keep you posted on my progress.

That’s all, folks! or Becoming Randall Stevens

Once again, I’ve let a month’s worth of dust gather on my blog.  But I have a good reason for being so busy!

Several good reasons, actually.

And here they are:

UCOSP has wrapped for the semester

This semester, I was a teaching assistant for the UCOSP (Undergraduate Capstone Open-source Projects) course.  I helped out with two projects:  MarkUs and Review Board.

This semester, we saw some outstanding work for both projects.  Lots of great students, lots of good code, lots of leaps forward.

I’m looking forward to helping out next semester with UCOSP.

I won’t be doing it as a paid teaching assistant though.  Why?  Well…

I’ve finished school

My research paper was signed off by my two readers, and I just wrote my last final exam a few nights ago.  Unofficial grades have been posted, and I’ve passed what I needed to pass.

So that’s that – I’m a Master of Computer Sciences, I guess.  Awesome!

I got a job!

I’ve been hired by Mozilla Messaging to work on the Thunderbird project!  I’m 100% psyched about this opportunity, and look forward to peeling into the code.  An added bonus:  since Thunderbird is an open-source project, I’m absolutely free to discuss the code and the various things I’m doing with it.  No NDAs for me!  So stay tuned – I’ll have lots to say about Thunderbird and the Mozilla Framework code.  Just give me some time to wade through it.

Zihuatanejo

It’s been a pretty long road.  I’ve been in school, in one form or another, for over two decades.  It’s strange that it’s over.  I’m extremely excited about my next adventures, but I think I’m going to miss school.

Still, I can’t help but be a bit dramatic…

[simage=735,288,y,center]

In 1966, Andy Dufresne escaped from Shawshank prison. All they found of him was a muddy set of prison clothes, a bar of soap, and an old rock hammer, damn near worn down to the nub. I remember thinking it would take a man six hundred years to tunnel through the wall with it. Old Andy did it in less than twenty. Oh, Andy loved geology. I imagine it appealed to his meticulous nature. An ice age here, million years of mountain building there. Geology is the study of pressure and time. That’s all it takes really, pressure, and time. …Andy crawled to freedom through five hundred yards of shit smelling foulness I can’t even imagine, or maybe I just don’t want to. Five hundred yards… that’s the length of five football fields, just shy of half a mile…

Andy Dufresne – who crawled through a river of shit and came out clean on the other side.

P.S.:  Here are some celebration rituals, if so inclined.