Mike Conley's Blog

If you’ve ever downloaded anything using Firefox, you’ve probably seen this fellow:

Early 2000′s baby, yeah!

This new window would pop up, and you could use it to manage and monitor your downloads.

There are a few problems with this new window:

• You had to switch back and forth from it just to see how close your downloads were to being finished

• It was easy to lose track of this window, especially when you had lots of windows open

• The window listed every download you’d ever started, meaning that it got slower to render as the list got longer and longer.

This is just scratching the surface. Suffice it to say that the downloads window left much to be desired.

So, your friendly neighbourhood Firefox Desktop team have been working hard to make things a whole lot better.

The Downloads Button and Panel

Starting in Firefox 20 (released today!), a new button will be added to your toolbar:

BEHOLD!

This button serves a number of purposes. For one thing, it tells you how long it will be until all of your downloads complete:

2 minutes until all of my downloads finish.

This button also animates when a download completes, and changes colour when all of your downloads are done:

Downloads are done!

Clicking on the button will show you your latest downloads:

Well, hello there.

And from here you can open your downloads easily. Not too shabby!

Like most things in Firefox, the new button can be moved to wherever you’d like it. Simply right click on your toolbar, and choose “Customize”, and drag the buttonto someplace new. Or, if you don’t want the button, you can drag it into the customize window to remove it completely (although, clearly you won’t be notified of downloads progress this way).

Manage your downloads in the Library

The downloads panel is a lightweight way to check the progress of your downloads. This is all well and good, but it doesn’t give us nearly the same power of the old downloads window. That’s why we have moved the functionality from the old downloads window into a new view in the Library.

Getting a fresh copy of Ubuntu 12.10.

The new manager has similar functionality to the old one, so you can search your downloads, clear them and even leave this window open while closing any other browser windows to complete downloads in the background.

Since this unifies the concept of downloads and history, there is no more risk of clearing downloads for privacy reasons, only to find that your history had retained them!

You’ll also notice that with the new per-window Private Browsing feature, downloads are managed separately by each window – the downloads manager opens in a tab so that you can easily manage your private downloads.

Just some wholesome browsing going on here.

This way, we make absolutely sure that your private downloads do not show up in your history, while still giving you full control over those downloads. Engagement ring PDFs for everybody!

Some tips and tricks

There are some neat shortcuts from the old manager that some of you may have used. We tried to retain those and even make them better.

• Pasting a url into the panel or the Library downloads view with CTRL-v will start a new download

• You can drag downloads from the panel or the Library to the desktop or any other path

• Related to this, you can download a PDF, and then drag it to the browser window to preview it using our built-in PDF viewer!

• You can drag a link to the downloads button to start a new download

• CTRL+j opens the Library directly in the Downloads section

Help us make it even better

If you find a bug in the new downloads experience, or you have enhancement requests for it, please file a bug in the Firefox / Downloads Panel component. You can also discuss the feature or your improvements ideas in the new firefox-dev mailing list.

On behalf of the team that helped make this thing happen (and folks, it’s been a long time coming), we hope you enjoy your new downloads experience in Firefox 20!

15 people like this post.

Like

Unlike

Now that the Australis curvy tabs are in the polishing state, it’s time I turn my attention to the second part of Australis – the new customization experience.

Customizing Firefox’s UI has always been a little bit funky – you right click on a piece of chrome and choose Customize (or if you knew about it, go to View > Toolbars > Customize), and then a window pops up that lets you drag items to and from it. When this window is open, you are in the customizing state, so you can move buttons all over the place.

The new customization experience that the UX team has designed is quite a bit smoother. I can describe it, or, even better, I can show it to you.

Instructions:

1. Go here to see bwinton’s awesome prototype
2. Hide the main navigation bar for a more immersive experience (View > Toolbars > Navigation Toolbar)
3. Click on the menu button in the right corner, and choose “Customize”
4. WHOA
5. Now drag some items from the customize palette onto the toolbar, or into your menu.

Pretty snazzy, and it does away with that old customize window, which is excellent.

Blair McBride has been working on this feature for a little while, but due to health issues, the project has been handed to Jared Wein and myself. And I suppose when Blair is back at 100%, it’ll be all three of us hacking on it. Or something like that.

So, everything I just wrote above? That was for you, to let you know what I’m looking at during my day. Everything below the “Notes to self…” header are my notes as I browse through the customization code as it is. Just going to jot down notes and observations, etc. You might find this interesting, since it will show you my thought process as I go.

Or you might think it’s just a confused and bewildered miasma of incoherent rambling and nonsense. Well, we’ll see how it goes.

Notes to self…

Glossary:

• Panel – the thing that opens when I click on the three-line menu toolbar button (a.k.a “the hamburger” – sorry shorlander) in the nav-bar
• Widget – what used to be considered “toolbarbuttons”. It’s a thing that can be in the panel, in the customize palette, or in a customizable toolbar
• Customize palette - what used to be a new window is now an in-content selection of widgets you can chuck into the panel or customizable toolbars

So I know we’ve got ourselves a panel, and there’s a whole bunch of customization logic. There was also this API thing that Blair was working on so that add-ons could specify widgets through their chrome.manifests. And there also appears to be some work to be somewhat backwards compatible with the ol’ overlay approach to adding widgets.

The big mama seems to be browser/modules/CustomizableUI.jsm. This module seems to be responsible for a ton of stuff, including (but not limited to):

• Panel open / closed state
• Panel populating
• Menu button pressed / unpressed state
• Persisting and restoring customization settings
• Catching “I dun get it” notifications from the chrome.manifest parser to see if it’s a widget that’s in there
  • Reading JARs or uncompressed files from the manifest to create widgets
• Being the central hub of knowledge about where widgets are, and firing notifications when widgets are added, removed, moved or destroyed.
• Knowing about which widgets are not being used, which lets us populate the palette tab when we enter customization mode
• Allowing us to enter and exit the customization mode
  • That appears to be leftover cruft.  browser/modules/CustomizeMode.jsm seems to manage that now. I’ll remove the old cruft.

There’s this notion of “customizable areas” too. It looks like we’re constraining the customizable areas for now, and so we have an area between the URL bar and the menu button that we can drag and drop items to. The panel is also an area. When we enter customization mode…

Ok, this is pretty neat. When we enter customization mode, we suck out the panel, and drop it into a panel holder in the customization tab. That way, we can see the panel and add to it while customizing. Ok, I get that.

There was originally the idea of de-coupling the panel from the customization code. That might actually still be possible. I had tried that earlier, but was discouraged when I found out that the CustomizationUI.jsm was responsible for populating the contents of that menu panel too, meaning that the panel code itself was rather useless without the customization stuff. Maybe this needs more thought – because it would be nice to de-couple them a bit more.

Maybe I should work harder at de-coupling the menu stuff from the customization stuff – especially now that it looks like the panel is a little more complicated than just a widget drop point. Now widgets can have “subviews”, like the bookmarks widget. This means that stuff either slides out or moves over in the panel when clicking on a particular widget. Having all of that jammed up in CustomizableUI.jsm isn’t ideal – maybe I can split it out to help us separate our concerns a bit more.

Ok, I think I’ve convinced myself. I’m going to spend the rest of the afternoon trying to devise a strategy to de-couple these two.

5 people like this post.

Like

Unlike

I wrote a while back about how Matt, Avi Halachmi and I have been ironing out performance problems with the Australis curvy tabs.

Well, it looks like that work is finally paying off.

Our SVG usage seemed to be the big slow-poke, and switching to PNGs gave us the boost that we needed.

But enough squawking, let’s see some charts.

Before Optimizations

Let’s compare – here’s a chart showing the difference between pre-curves and post-curves, before our optimizations:

Here’s the before shot

Note: it’s been a while since I’ve done data visualization work. I think the last time I did this was in grad school. So there might be way better ways of visualizing this data, but I just chose the easiest chart I could manage with Google Docs. Just go with it.

Let me describe what you’re seeing here – we take samples every time a tab opens, and every time a tab closes*. What we’re measuring is the interval time (how long it takes before we start drawing the next frame), and the paint time (how long it takes to actually draw a frame).

The blue bars represent the performance measurements we took on a build using the default theme.  The red bars represent the performance measurements we took using the Australis curvy tabs.

This is where my graph could probably be clearer – in each group of four bars, the left two represent interval times, and the right two represent paint times.

So, hand-wavey interpretation – we regressed in terms of performance in both painting, and frame intervals, for tab opening and closing.

So that’s what we started with. And then we did our optimizations. So where did we get to?

After Optimizations

Here’s the after shot!

The red bars shrunk, meaning that we got faster for both interval and paint times. In fact, for tab close, we beat the old theme! And we’re really super-close for tab open.

Pretty good!

Curvy tabs for all

Last night, Matt landed our optimization patches, as well as preliminary curvy tab work for OSX* and Linux GTK on our UX branch. So, if you’re on the UX branch (and why aren’t you?), you should be receiving a build soon with some curvy tabs. They’re not perfect, not by a long shot, but we’re getting into the polish stage now, which is good.

* Some notes on our measuring methodology. All tests were performed on a low-powered Acer Aspire One netbook. Intel Atom n450 processor (1.66Ghz), 1GB of RAM, running Windows 7. The device has no graphics acceleration support. We also switched to the classic theme to avoid glass. Avi wrote a patch that opened and closed a tab 15 times, and averaging the frame intervals and paint times for each frame. Those were averaged over the 15 openings and closings. We then ran that test 4 times, giving the machine time to “relax” in between, and averaged our results.

* We don’t have hi-dpi support yet, so if you’re on a Mac with a Retina display, your curves might be fuzzy. We’re working on it.

8 people like this post.

Like

Unlike

The Firefox desktop team gathered in Toronto a few weeks back to hack together, and to discuss how we’re going to tackle 2013.

I can tell you right now, it’s going to be a fantastic year for Firefox.

Asa Dotzler has a great high-level write-up of some of the stuff we talked about, but I want to focus in on something Matt Noorenberghe and I were working on: beautiful curvy tabs.

Mmmmm…that’s the stuff.

That’s what I’m talking about, right there.

These curvy-tabs are already available for Windows in the UX Nightly builds, and I’ve been using them for a few weeks. And they feel great. It’s actually painful to go back to the boxy, noisy, square tabs in the current default theme. Using the old boxy tabs feels like I’ve gone back in time – and not in a cool way.

Even Chrome’s 45° angle tabs feel just a little too machine-like and impersonal in comparison, in my opinion.

Chrome’s 45° tabs

Having a more fluid and minimal tab strip in Firefox is great, but it’s only great if it performs well. Fluid and fast is the name of the game, and that’s what Matt and I were looking at; we were trying to find ways of speeding up tab opening and closing animations.

We’ve been working with the Performance Team on this, and we’ve been gathering some really interesting data. Probably the most interesting stuff is when we make a change that we expect to improve performance, and it doesn’t deliver. Or, even worse, it causes performance to be poorer. That’s usually a very surprising result.

We ran into such a result late last week, when we tried changing how we put a gradient on top of the selected and hovered tabs. We had originally been using the CSS linear-gradient function, and the Graphics Team told us that using a tiled background-image with some opacity (like a PNG) would improve performance.

Well, we generated our gradient as a PNG, tossed it in, and did our measurements. Lo and behold, performance worsened somewhat, and we’re still not exactly sure why. I’ve filed a bug on this, and I’m hoping we can get it resolved soon. Switching to PNGs for gradients was supposed to be an easy win, and the Graphics Team was pretty surprised by our result.

Matt and I tried a bunch of different ideas to speed up tab animations, and slowly but surely, the needle started to move in our favour. We’re getting close to matching the performance of the current square tabs, but we’re going to see if we can push it over the edge and bank ourselves an overall performance win.

Fluid is good, but fluid and fast is the best. We’re getting there.

7 people like this post.

Like

Unlike

The developers of the puzzle game Cut The Rope have ported their code from Objective-C to Javascript and HTML5.

And, despite the IE slant, the game works really well in Firefox!  Check it out:

Visit http://www.cuttherope.ie to try it out!

7 people like this post.

Like

Unlike

Some fine fellow has written some Javascript that runs one of my favourite games in the browser.  I just watched the opening cutscene of Monkey Island in Firefox!

It’s still a bit buggy, but it’s a start!

Here’s the source code.

5 people like this post.

Like

Unlike

My friend Joel Beck is kind of a badass.

When he’s not designing / building reactors for Atlantic Hydrogen in New Brunswick, he’s learning all sorts of cool skills.

Skills like leather-working.

Look what he gave me as an early Xmas gift:

View at Picasa A hand-made leather wallet by my friend Joel Beck10-Dec-2011 22:44, google Nexus S, 2.6, 3.43mm, 0.017 sec, ISO 50

View at Picasa Thunderbird!10-Dec-2011 22:44, google Nexus S, 2.6, 3.43mm, 0.008 sec, ISO 50

View at Picasa Firefox!10-Dec-2011 22:44, google Nexus S, 2.6, 3.43mm, 0.008 sec, ISO 100

View at Picasa 10-Dec-2011 22:45, google Nexus S, 2.6, 3.43mm, 0.008 sec, ISO 100

View at Picasa 10-Dec-2011 22:45, google Nexus S, 2.6, 3.43mm, 0.008 sec, ISO 50

View at Picasa Just look at that detail.10-Dec-2011 22:45, google Nexus S, 2.6, 3.43mm, 0.003 sec, ISO 50

View at Picasa Mind = blown.10-Dec-2011 22:45, google Nexus S, 2.6, 3.43mm, 0.004 sec, ISO 50

This is a one-of-a-kind, hand-made leather wallet, made by my good friend Joel Beck.

Thanks Joel.

7 people like this post.

Like

Unlike

So, I just started my day off with a big bowl of Apple Cinnamon Cheerios and some fresh orange juice, c/o Mozilla Messaging.  Thanks, team. 

Another great thing about Mozilla is that, since its spread out around the world, somebody is awake and working pretty much 24 hours a day.  That means if I write a bunch of code and go to bed, there’s a chance that when I wake up the next morning, the code review is done and I have some feedback on my next steps.

And that’s more or less what’s happened at the start of today.  That add-ons manager grouping feature I was working on for Firefox got looked at in the night, and I got some feedback on some changes I can make.  Awesome.

So here’s the scoop:

First off, a conversation got started regarding where add-ons with pending installs or uninstalls go.  The answer:  pending installs should go into the group they’ll be in once the install is complete, and pending uninstalls should stay in the group that they were in when the install happened (in order to prevent the add-on from jumping around in the list).  That’s good – that makes my job easier, I think.

With regards to implementation, I don’t think my nifty Shwarzian Transform is gonna fly:

I don’t think that this is the right approach to take here. Instead the more straightforward way is to just make sortElements accept an array for aSortBy (and update all callers to pass one) of fields to sort by in order of preference. If the elements match by the first field then move onto the second and so on. For the non-search list views use a specially named field “uiState” and then use your function as the comparison function for that field.

(from one of my reviewers)

So this approach involves me changing a bit more code.  See, my original approach was to try to change as little as possible.  I guess that’s just me being the “new guy”, and trying not to rock the boat.  But clearly, they want me to go deeper.  I’m happy to oblige!

But there’s a bit more complication.  According to the Bugzilla page, this bug I’m working on depends on this other bug, where somebody else is also tinkering with the sorting functions.  That means I have to be uuber careful, and make sure to base my work off of their patches.

In particular, it looks like this patch is going to be altering the sorting tests, and removing the ability for Firefox users to sort add-ons by anything besides the add-on name.

So what I’m going to do is download and apply this patch, and then start basing my work off of it.  Each time the patch is updated in Bug 623207, I’ll just re-base my work off of it.  Nice.

Ok, so first of all, I wipe out my old work using hg strip (using Blake’s handy script to find the HEAD revision number of that branch).  Next, I grab the patch for 623207, and use patch to apply it.  Then, I use pnew to create a new pbranch with that change, and then create another pbranch on top of that.  That second pbranch is where I’ll do my work.  If/when the patch to 623207 gets updated, I’ll update the first pbranch, and then merge it into the second.  Awesome-sauce.

Argh.  It seems I have to recompile in order to get that 623207 patch to work.  And not an incremental compile either, since “make” doesn’t seem to do much in toolkit/mozapps/extensions.  *sigh*…compiling…

Just stopped by UofT to drop off my old keys, and get my old computer wiped.  Stopped by and talked to Karen, and helped two new MarkUs students.  Kind of bitter sweet moment.  Goodbye school.  It was a long battle.  Well played.

I’ve finished a draft of my add-on grouper/stratifier.  Now I’m going to check out these tests.  Without my change, the tests in browser_sorting.js all pass.  With my patch, 3 fail.  Ok, so I think I’ve found the right tests.  Lets see whats up…

Ok, it looks like the tests were trying to call my new sorter, and didn’t know that it had to pass an Array instead of a string.  Fixed that, and all tests are passing.  Sweet.

Now let me try all of the extension tests…ok, without my patch, 10 fail.  With my patch… OH SHIT.  194 failures.  That’s a big deal.

Ok, I think I’ve fixed those tests.  But now when I run the extension tests, one of the tests seems to take forever…what’s the deal?  Turns out, this test does this periodically, even without my patch.  Hrm. So I guess I don’t have to worry about it.

After a few runs, I’ve got the same number of passing tests as there were before my patch:  only 10 fail.  Nice.

So now I have to try to write some new tests.

Suite!  Tests written.

It takes me a while to run the Firefox Mochitests on my machine.  If I were to do them all, it’d probably take at least an hour.  Running the add-ons manager tests takes about 5 minutes.  And in either case, I can’t use my machine, because Mochitest needs me to keep focus on Firefox while its running the tests.  Basically, this means if I want to run the tests, I give up my machine, and go snack on something in the kitchen.  That was cool at first, but after a while, giving up my machine for 5 minutes seemed pretty lame.

So, luckily, there’s a machine in the office called TheFlash, and, as its name suggests, it’s SUPER fast.  Like, lightning speed.  Compiling Thunderbird from scratch?  7 minutes flat.  Jeebus.  Anyhow, Blake got me an account on TheFlash, and I’ve pushed my changes to a Firefox instance over there.  Firefox is compiling, and then I’ll try out my tests over there.  Awesome.

Tests pass!  Lovely.  And Blake just took a look at my code and showed me a neat trick:

So I’ve got an Array of uiState’s, like so:

const UISTATE_ORDER = ["enabled", "incompatible", "disabled", "blocked"]

And I wanted to sort a collection of these values in order that they appear in that Array. So something like:

["disabled", "disabled", "blocked", "incompatible", "disabled", "enabled", "enabled", "blocked", "disabled"]

# Would become

["enabled", "enabled", "incompatible", "disabled", "disabled", "disabled", "disabled", "blocked", "blocked"]

(this sort of thing is useful if each of those original entries is associated with something like, I don’t know, a Firefox add-on…)

In Javascript, we use a sort command, and we pass a function to do comparisons.  Normally, I’d do something like:

function uiStateCompare(a, b) {
 if(UISTATE_ORDER.indexOf(a) < UISTATE_ORDER.indexOf(b))
   return -1;
 if(UISTATE_ORDER.indexOf(a) > UISTATE_ORDER.indexOf(b))
   return 1;
 return 0;
}

But there’s a more concise way to say this:

function uiStateCompare(a, b) {
  return (UISTATE_ORDER.indexOf(a) - UISTATE_ORDER.indexOf(b));
}

Which makes total sense.  If UISTATE_ORDER.indexOf(a) < UISTATE_ORDER.indexOf(b), then of course the difference is less than 1.  Anyhow, I thought this was a pretty neat trick.  Thanks Blake.

Alright, patch is scrubbed and ready for posting on Bugzilla….here goes!

Ok, patch posted.  Home time.

Be the first to like.

Like

Unlike

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.

Be the first to like.

Like

Unlike

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:

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.

Like

Unlike