Posts tagged ‘mozilla messaging’

MoMo’s No Mo’, Yo!

In an effort to increase and focus our efforts on messaging and web communications, Mozilla Messaging is being absorbed by Mozilla Labs!

Check out these explanatory blog posts by David Ascher and Mitchell Baker.

P.S.  Yes, I’ve been sitting on that title for weeks.

2 people like this post.

MoMo All-Hands: Day 4 (Another Gorgeous Day, and then a Dicey Situation at Night)

As usual, I woke up, grabbed a shower, and headed down to breakfast.  The routine was really starting to sink in.

Breakfast was yogurt, croissants, and granola, with little cakes.  Very tasty.  And the weather?  Gorgeous as usual.

After breakfast, we were underway.  There was lots of talk about features in the upcoming version of Thunderbird.  There was a long talk where we batted around ideas on how to reward contributers to Thunderbird.

I got a lot done that day – I’d been having some trouble getting Ubuntu Natty running on my laptop virtual machine, and I finally got it going.  I kicked off a Thunderbird debug build, and got the globalmenu extension I was tinkering with compiled.  I had a segfault to solve, and I dug into that.

Around five, we broke for dinner.  Everybody was going to different places, and I chose an Italian restaurant called Il Lupino with Karen, Gozer, Shane, and Mark Banner.  The restaurant was new, and seemed like they were still getting their act together.  It seemed like there were a lot of waiters standing around not doing much, and only one or two staff running around doing a whole bunch.

It was a bit of a wait, but they fed us bread.  Eventually, dinner arrived, and it was tasty.

After dinner, we walked back to the hotel along the beach.  It was a nice, cool night.  There was a super fine mist in the air, which I gather is the Hawaiian version of a light rain.

When we got back to the hotel, a bunch of people were playing XBox in the meeting room.  I watched for a bit, played a few rounds, and eventually called it a night.

Trapped

I headed up to my hotel room, and started getting ready for bed.  As I was brushing my teeth, I noticed something strange about my bathroom.

The bathroom was divided up into two sections.  One section had the sink, a big mirror, and a bathtub.  The other section was where the toilet and the standup shower were.  The sections were divided by a doorway that didn’t have a door to go with.

Or so it seemed.  On closer inspection, it turned out there was a door to go with the doorway.  It was a sliding door, like one might have to out onto a back patio, and it was recessed into the side of the doorway.

I was curious, so I pulled it out to take a look at it:

27-Jan-2011 04:57, FUJIFILM FinePix A345, 2.8, 5.8mm, 0.033 sec, ISO 100

The only feature on the door was a little metal plate for sliding it back and forth:

27-Jan-2011 04:57, FUJIFILM FinePix A345, 2.8, 5.8mm, 0.033 sec, ISO 100

And you’ll notice that in the center of the little metal plate is a white button.

I’m a naturally curious guy, and I wanted to see how the locking mechanism worked.  So I closed the door, and pressed the white button.

It only took me a few seconds to realize that there was no way to un-press the white button. I had just trapped myself into the toilet/shower side of the doorway.

At first, I thought this was really funny.  What a stupid design for a door!  After a few seconds of laughing at myself, the gravity of my situation started to sink in:

  1. I had no cell phone to call for help.  No roommate who’d be coming in.
  2. Nobody would be looking for me until morning.
  3. The door didn’t have any hinges for me to take apart.  And, because it was a sliding door, it meant that all edges of the door were recessed into the doorframe, which meant no kicking it down.
  4. I’d put the “do not disturb” on my door, so I couldn’t count on the cleaning lady to let me in in the morning.
  5. The space in that section was about the size of two phone-booths combined.  If I had to sleep there, it’d be an uncomfortable night.
  6. It was late, so banging on the walls and making a huge ruckus was probably a last option.  And there was no guarantee that any of the rooms near me were occupied.

It was a sticky situation.  Not life-threatening by any means, but quite a predicament nonetheless.

Macgyver

So, after thoroughly examining the lock, my first step was to take an inventory of my tools:

  1. There were towels and toilet paper.  I didn’t see how I could use those on the lock.
  2. The contents of the toilet tank included the floater ball, and a chain for the drain mechanism.
  3. The shower head was connected to the faucet via a snaky metallic tube that could be disconnected at both ends.
  4. I was carrying my wallet, which had some paper money, and some coins.
  5. I was wearing my belt.
  6. I had shorts on, and the metal tab on my zipper could possibly be used as a screwdriver.

I decided to attack the lock with my belt.  I rammed the swing-arm on the belt buckle into the area between the white button and the metal plate, seeing if I could make some room on either side of it.  I ended up working away some of the plastic on the button, and was able to make some space.

Ok, so now I could wiggle the button back and forth.

Continuing with my belt, I tried to “scoop” the button out – but the plastic was too slippery, and I didn’t seem to be making and progress.  And, at some points, it seemed like the button was going farther in, and I really didn’t want to make my situation any worse.

I switched tools, opened up my change wallet, and pulled out two dimes.  My fingers were too big to pinch the button and pull out, so I tried using the dimes.

It was starting to get hot in there.

With one dime pinched in each hand, I worked them like the world’s most awkward tweezers.  I grabbed the button, squeezed inwards towards the button, and tried to pull out.

The button was slick, and the dimes kept slipping off.  It didn’t look good.

And then…

Suddenly, I had a good grip on the button, and the dimes pulled it out.

I fist-pumped, slid the door open, and enjoyed the cool air.  I’d been trapped for about 25 minutes.  It was good to be out.

And then I took some photos.  Here’s a shot of the toilet/shower room just after I escaped:

27-Jan-2011 04:57, FUJIFILM FinePix A345, 2.8, 5.8mm, 0.033 sec, ISO 100

and here’s a shot of my trusty, if clumsy, tools:

27-Jan-2011 04:57, FUJIFILM FinePix A345, 2.8, 5.8mm, 0.033 sec, ISO 100

I went to bed pretty exhilarated.  I was looking forward to telling everybody about this at breakfast the next morning.

4 people like this post.

MoMo All-Hands: Day 3 (Data-Driven, Don’t Be Creepy, Italian-Chinese Dinner, Hipster-slamming)

At around 7:30AM, I rolled out of bed, cleaned myself up, and headed down to breakfast.

Breakfast that day was similar to the day before:  yogurt and granola.  Coffee and juice.  The cakes, however, had gotten the axe, and had been replaced by scones.

Very tasty.  A bunch of us ate breakfast out on the meeting room patio.  Once again, it was a gorgeous morning.

After breakfast, we all went inside to talk about data. Specifically, that we aim to be data-driven.  This means that if we’re making a big decision about Thunderbird, or any of the other stuff we’re working on, we should probably have some solid data to back up those decisions.  It’s a good idea; the road to bad design is paved with good intentions, and lack of data.

But how exactly are we going to get this data?  Are we simply going to monitor our users without their knowledge, like Big Brother, and study them like lab rats?  Are we going to collect reams of data about them secretly and silently in the background, without telling our users or giving them a choice?

Of course not, because that’d be evil.  And creepy.  Don’t track me, bro.

Instead, we will always ask the user if they’re interested in submitting data for study.  In general, our data collection is opt-in – and instead of tracking individuals, we aggregate the data, so that we never have a single person as a data point.  Nice.

A lot of ideas got tossed around about how we can ask the users for data, and what type of data we were interested in.  Some very interesting discussions took place regarding the Thunderbird “funnel” (the action path from visiting the Mozilla Thunderbird website, to downloading TB, to installing TB, to running TB, to making TB something commonly used).  Our funnel is pretty wide, but some website tweaks might make it even wider.  I’m excited to hear more about it.

After that, lunch.  Roasted chicken, mashed potatoes, veggies…once again, very tasty.  Cake for dessert.  We were getting pretty spoiled.

Following lunch, a bunch of us went outside to hear Andrew Sutherland talk about Wmsy – his constraint-based widgeting framework.  This was one of the talks that took place out on the patio, and the sun was blazing.  Much sunscreen had to go on, and I wish I’d brought sunglasses, because the image of the giant yellow pads of paper-on-easels that Andrew was drawing on was slowly being burnt into my retinas.  And then, sunscreen started getting into my eyes.  And yet, despite the blazing heat, the blinding sun, and the burning chemicals in my eyes, I was able to get a lot out of the talk.  Wmsy is pretty cool, and you should check it out.

After that, we went inside, and there was a bunch of GSoC talk.  Mentors talked about how it was working with GSoC students, and what kind of GSoC students we’d be looking for.  Then, a big brainstorm happened where we came up with potential GSoC projects.

Photo Credit:  Ludovic Hirlimann

Photo Credit: Ludovic Hirlimann

As a former GSoC student, I have to say, it’s a really worthwhile program.  I had an awesome summer doing GSoC.  Highly recommended.  Thumbs up, Google.

After that, the meetings were over.  I headed upstairs to talk to my parents and Emily on Skype for a bit, and then headed down to the lobby for dinner.  A group of us were eating at “Chow Mein”, an Italian-Chinese fusion restaurant.

It was pretty good. Fettuccine on one side of my plate, barbecue pork fried rice on the other, and some salad…a delicious and eclectic meal.  As an added bonus, while refilling our glasses, our waiter told us in excruciating detail about how he got pulled over for DUI on his birthday.  On that note, we had a fantastic dessert, and then left.

The sun was down, and we walked slowly along the beach back towards the hotel.  We stopped off at the beach-side patio to hang out a bit first.

Photo Credit: Blake Winton

Photo Credit: Blake Winton

We raced Mai Tai umbrellas, and trash-talked hipsters.  It was probably the most hipster thing I did in Hawaii.

And speaking of hipsters (mildly NSFW):

Eventually, I made it back to my hotel room, and fell asleep.

2 people like this post.

MoMo All-Hands: Day 1

A Delicious Flight

After waking up, cleaning up, and eating, I was more or less ready to go.  Blake was stopping by around 11:30AM with the airport taxi, and I had about an hour to myself.  I decided that now would be a wonderful opportunity to purchase some flying snacks from the nearby convenience store.

Moments later, I was browsing the shelves.  I grabbed some granola bars, and some raisins.  On my way out, I saw some flatbread, and was immediately reminded of the time that my friend Doug offered me some flatbread with roasted red pepper hummus on it.  And I remembered that it was delicious.  Immediately, I was hit by a craving, grabbed the flatbread, and went to go find the hummus.

Eventually, I zeroed in on the hummus section.  Unfortunately, the tub of roasted red pepper hummus that I found was about the right size for a whole family, and I thought that’d be a bit of a waste (since I wasn’t sure I’d be able to refridgerate it upon landing).  So I dug around in the shelves until I found a smaller tub, grabbed it, paid, and left.

Now, I know what you’re thinking:  “Mike – this minutia is really of no interest to me.  Am I really going to have to hear about the food you bought and ate?  Is this how these posts are going to go?”.  Just rest assured, I’m bringing this up for a reason.  The hummus comes into play later.

Blake arrived, I hopped into the car, and we were off.  We compared snacks:  Blake was packing some awesome-looking homemade banana bread with chocolate chips.

It was going to be a delicious flight.

A Newbie Goes Through Security

It’d been a little while since I’d been through airport security, and I had forgotten some of the moves.  I did my best to follow Blake’s example – I pulled out my laptop to be screened independently.  I tossed down my jacket.  I lined it all up all neat and tidy for the little luggage car-wash to scan it.

Soon, it was my turn to walk through the metal detector.  In front of me, Blake had sailed through and was already getting his stuff off of the conveyer belt.

I walked through the gate.  BEEP BEEP BEEP BEEP.

“Sir, do you have anything in your pockets?”

Oh yeah.  I had everything in my pockets.  Wallet, keys, cell-phone, belt, watch, I’d forgotten all of it.  So there I am, scrambling to void my pockets of their contents, and tossing them into a little bowl to be scanned.

Security was not impressed.

After an extremely thorough wand-scanning, I was eventually let through.  I gathered my stuff up, and hurried over to Blake.

The Storage Seat

We reached our terminal without incident.  We had an hour to kill before boarding, and chatted about the upcoming meeting, science fiction, Ricky Gervais, video games.  Boarding was a piece of cake.

Although we had booked our tickets seperately, somehow, our seats were in the same row.  There was a lone seat in between us.  The plane filled up…and filled up…and the seat remained empty.  Suddenly it dawned on me:  Blake and I were probably about to get a free storage seat between us.  Awesome-sauce.

I became so excited about the middle seat that I was starting to sweat everytime someone else came onto the plane.  One or two stragglers would saunter on, and I was sure the jig was up.  But somehow, someway, it didn’t happen.  The storage seat was saved.  It immediately became home to a host of overflow items.

Take-off

It was at this point that the captain came on the horn to tell us that there was a problem.  During the safety check, he found out his oxygen mask wasn’t working.  Maintenance would be sending a part over, and it’d take somewhere around 30 minutes to get it all sorted.

30 minutes later, we were underway, and hurtling down the tarmac.  Eventually, the seatbelt sign was turned off.  I reached for my book.  It was going to be a long flight (approx 6 hours).

That’s when the flight attendant announced that the water wasn’t running in the front bathroom.  So we were down to one bathroom.  The girl across the aisle from me groaned audibly.

Moments later, we found out that our in-flight movies were not working.  The same girl groaned even louder, whipped out her cellphone, and began texting furiously.  I was reminded of this Louis C.K. bit on Conan…

It was an uneventful flight.  Blake and I chatted a bit, and then I read, and he listened to music.  There was a Mythbusters marathon on the on-board television, so that was entertaining.  I learned today that if a diver in one of those old-school scuba suits is down 300 feet, and suddenly has his air supply cut off…the waterpressure is strong enough to compress all of his organs into his helmet like a human meatball.  Gross. Thanks Mythbusters.

Landing, and the Hummus Incident

Landing was no biggie.  The captain came on the horn again to tell us that they had to cut power the plane in order to get the bridge attached to us.  As the lights went out, I could see the light of a cellphone illuminate the face of the girl across the aisle.  Texting commenced at a furious pace.  I don’t think she was very happy with the flight.

Next, Blake and I meandered our way to U.S. security and customs.  Along the way, we helped a mother and daughter find their New Zealand flight.  While in the line-up, I realized that I was still carrying a bottle of water that I’d purchased in the Toronto airport.  And it was still more or less full.

To avoid embarrassment, I chugged it back.  The whole half-litre.  Dazed from over-hydration, I tossed all of my gear, pockets and all, upon the security conveyor belt like a boss.  I was determined to do this like a pro, and gave Blake the “I know what I’m doing this time” eyebrows.

Shoeless, beltless, pockets emptied, I passed through the metal detector like a marathon runner at the end of a race.  Not a sound from the machine.  It was glorious.

“Step over this way, sir”.

I was suddenly redirected to security, and told to empty my backpack.

As the security guard rummaged, my hummus fell out, and wobbled onto the table.

Suddenly, all eyes went to the hummus.

“Sir, what is this?”

“It’s hummus.”

“No, it’s not.”  I looked closer.  Damn it, I’d been duped by similar packaging.  It was full-blown dip, not hummus.  So much for healthy snacking.

“Oh, sorry, it’s dip.  Not hummus.  Dip.”

Pause.

“Sir, I’m going to have to ask you to stay right here.”

I had started to sweat a little.  Meanwhile, Blake was getting his shoes on, and was eyeing me curiously.

“It’s the hummus,” I said.  He mouthed “Oh”.

3 or 4 minutes later, I was shuttled over to an official looking desk, where an official looking guard was presiding over my very fraudulant hummus.

“I thought it was hummus.  You can keep the dip.  I don’t want to the dip.  You can have the dip.”  I kept saying.  I was worried that they thought I’d lied to them while calling it hummus.  Or was there some sort of dip embargo?  What the hell was going on?

“I don’t want the dip,” the tired looking employee said to me.  He had a thousand-yard stare going on.  This guy was not a fan of his job – at least not today.

“Your boarding pass says that you came in from Toronto.  They should have stopped it at security over there”.  He jabbed a finger at the dip.  “This is over 50 millilitres of liquid.  They shouldn’t have let it through.”

I made a weak attempt at humor by mentioning that the dip wasn’t exactly a liquid, and was more like handcream.  He didn’t seem amused.  I cut the crap and shut my mouth.

He then spent 5 minutes collecting all of my personal identification, and taking photos of me with the security camera.  He assured me that I wasn’t in trouble, and that, in fact, Toronto airport security was in trouble.  I remarked that I hoped nobody was going to lose their job over this.  He grunted, handed me my boarding pass, and wished me a good day.

Dip-less, I walked back to Blake, gathered up all of my stuff, and we started walking towards our departure gate.

A Chance Encounter

We had stopped by a Tim Hortons to grab some food, when Blake nudged me.

“Come this way,” he said.  I followed him back to the Tim Hortons line-up

“Mike Conley, meet David Ascher.  David Ascher, meet Mike Conley.”

So it turned out that David Ascher, CEO of Mozilla Messaging, and my new boss, was taking the same flight with his wife.  We said hello, and chatted a bit, and then headed towards our gate.

Huh.  What were the chances?

We boarded without incident.  Blake and I weren’t sitting together on this flight – I was sitting next to some charming older ladies who were slamming back the in-flight alcohol like it was going out of style.

In Hawaii

It was a hard leg of the flight.  After approximately forever, we landed.  This was at about 10PM Hawaii time, or 3AM Toronto time.  At this point, I’d been awake for about 19 hours.  I was exhausted, groggy, and probably dehydrated.

A section of the airport terminal had no windows.  It was warm out, but not uncomfortably so.  It was a bit humid.  I saw palm trees in the shadows.

Eventually, David, his wife, Blake and myself were able to hail a cab.  We whisked through the Hawaiian night.  I remember thinking that the outside part Hawaii we were driving through seemed like an interesting mix of industrial and tourist.  Kind of like if Niagara Falls and Hamilton were smashed together.

Finally, we pulled up to our hotel.  After checking in, my body had pretty much given up.

It’s funny how 19 hours of just sitting still in a chair will exhaust you.

Before reaching the elevators, we ran into a few more members of the team who’d arrived before us.  There were quick introductions (too quick – I’d have to ask for names again later on), and then we were up to our rooms.

Inside my room, I dumped by bag, plugged in my laptop, and sent a few e-mails to let people know I had arrived safely.  I prepared for bed.

As I rummaged through my luggage, something was bugging me…

“Hm…let’s see…shorts, pants, underwear, shirts…”

My eyes went wide.

No socks.

I hadn’t brought socks.

Click here to go to Part 2.

Click here to go back to the introduction.

3 people like this post.

MoMo All-Hands. In Hawaii.

It’s been a little while since I posted.  Well, I’ve been busy.

In Hawaii.

That’s right.  Hawaii.  Mozilla Messaging just sent the entire team to Hawaii for an all-hands meeting.  And, believe it or not, we got a hell of a lot done.  It’s amazing how productive people can be in shorts, Hawaiian shirts, and sandals!  No joke!

It was also an opportunity for me to meet my new teammates.  It’s a fantastic group, and a very warm welcome.  They’re smart, committed, quirky, and hilarious.  I think I’m really going to enjoy working with this team.

Anyhow, I had a great time, and learned a lot.

And I took notes.

Here’s part 1…

1 person likes this post.

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.

Be the first to like.

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!

Be the first to like.