Once upon a time (1st December 2012), in a land far far away (New Zealand), there lived a great bearded wizard (that's me), tormented by an evil troll.

Ok, so that's not a troll — it's our old garden shed. Although I do consider it to be slightly evil now.

Notice the grape vine creeping up the trellis; I was attaching the trellis to the wall of the shed one bright Saturday afternoon. I bent down to pick something up, stood up and turned around, and in a fit of bloody revenge the shed viciously attacked me. Or I may have just hit my head on the corner of the shed — I don't specifically remember that part. I vaguely remember feeling well enough afterwards to finish the job and clean up; though afterwards I did need to retire inside for a rest on the couch, then have an early night.

Sunday morning was quite the opposite of “feeling well enough”. “Awful” is a much more accurate description. I'm usually very resistant to see any doctor, but I got there as soon as I could on Monday. The medical field seems to involve a lot of inexact science (or as I like to call it, “guessing”), and my doctor's best guess was a pinched nerve in my neck and a concussion. I knew very little about concussions, but my doctor warned me to stay away from computer screens and books.

Now, I'll admit to a fair amount of ignorance here, as at this stage I expected to have an easy (if somewhat boring) time and be back at work after a week. Obviously, that didn't exactly go to plan.

In fact, I was so wrong that on Tuesday Anne and I planned to take a trip out of town (Anne driving, of course) so I wouldn't be completely bored out of my mind. We got as far as the emergency department of the hospital. Nothing serious, but I did learn that even sitting as a passenger in a moving car was enough to bring on some very worrying symptoms. Confusion, disorientation, difficulty focusing attention, blurry vision, double vision, atrocious headache, nausea, etc. All of which turned out to be normal, for a concussion — but nevertheless scary to experience.

I think most people don't have much of an understanding as to how a concussion (or any brain injury) can affect a person. I certainly didn't. This lack of understanding, and the types of symptoms and limitations, can be very isolating. As it turns out, being a programmer involves doing everything that you're not allowed to do when you have a concussion:

• In front of a screen
• Reading
• Concentrating
• Thinking

Yea, really — I was pretty much banned from thinking. And for good reason — thinking made my head feel awful. Interestingly, I was also banned from doing much physical exercise. I found I was very easily physically exhausted, as well as mentally exhausted. Conversations with people overloaded my brain very easily, and I couldn't cope at all with listening to groups of people. Both the mental and physical symptoms are caused by what's called neurogenic fatigue — which apparently is remarkably similar to sleep deprivation. And so the trouble with a concussion is that you can't push yourself to recover faster — it just ends up making things worse.

So I was stuck for most of December trying my best to do as little as possible. I plan on writing a separate blog post about this, but it's actually quite difficult to do nothing — really do nothing. I spent a lot of time sleeping, or laying on the couch or outside trying to keep my mind blank. Some forms of meditation worked, but many involve too much concentration. Most days I had a short trip into a quiet café somewhere — I've never been in cafés so often before in my life. Needless to say, it was a remarkably boring time. But thankfully this was during a very pleasant New Zealand summer, which permitted plenty of time lounging in the sun and quiet walks along the waterfront of St Clair beach (yea, such a hard life).

Oh, and of course it helped having my attentive friend Harley keeping me company:

On 18th December I was given the all-clear to start slowly returning to normalcy. On 3rd January I was told I could start reading work email for an hour, spread out over a day, every second day. It took me until 1st February to build up to being able to work half a day, albeit still not coding. If this seems slow, it was — agonisingly slow.

It's 14th February now (for me, at least - yay timezones) and I'm still doing roughly half days, but building up what I'm doing. So I'm finally getting through my review queue, some technical reading, and generally catching up on things I missed. Hopefully I'll soon be able to get back into some serious coding, help finish that little project I started last year, and generally be back into my normal routine. In the meantime, I'm a delicate little flower, so please don't bury me with too much work :)

No related posts.

Currently, when a restartless extension is installed, it's startup() function is called before the onInstalled and onInstallEnded events are fired. This meant that a restartless extension would run it's initialization code before anything else thought it was installed.

However, that causes some issues. For example, if a restartless extension uninstalled itself on startup^[1], then it could be uninstalled before it was installed. Unsurprisingly, the Add-ons Manager UI broke when this happened (since it uses the same APIs that add-ons use).

So bug 727398 will change the order of those operations. When a restartless extension installs, the following will happen in this order:

1. The extension's install() method will be called
2. onInstalled event will fire (AddonListener)
3. onInstallEnded event will fire (InstallListener)
4. The extension's startup() method will be called

Update: This change will ship in Firefox update 14, which is scheduled to be released on 2012-07-17.

[1] Why would an addon immediately uninstall itself, you ask? Imagine an add-on whose sole purpose was to flip a preference to disable a newly-shipped but buggy feature, that would get re-enabled on the next application update. This is one of the things that a hotfix add-on could do. Additionally, I've been playing with various ideas for restartless extensions as a user support tool - the extension installs, does some work or collects some diagnostic data, then immediately removes itself.

Related posts:

1. The Add-ons Manager and I are rather good chums
2. Solving Firefox’s add-on compatibility problem
3. Status update: Extension Manager UI, Tab matches in Awesomebar

Because of that little add-on, one of my first projects after I started working at Mozilla was teaching the Add-ons Manager about outdated plugins. The theory was that since I had worked on that add-on, I should already have some background in working with the Add-ons Manager code. Hah... Yea, no, that didn't help at all. That feature eventually shipped in Firefox 3.6, which now feels like an eon ago.

With a whole two Add-ons Manager related things under my belt, I must have earned myself a reputation for really loving anything to do with the Add-ons Manager. So late in 2009 I was asked if I'd like to help Dave Townsend with the re-write of the Add-ons Manager that he had been planning for some time (with Jennifer Boriss Morrow for UX, and Henrik Skupin for QA). It would be just a short project, helping out with the new UI - nothing major, I'd be able to get back to finishing my other project soon enough. Turned out that at that stage there was no UI yet... and it would take about a year for me to write it. The first very basic iteration was written during my Christmas holiday in Motueka, a few days later I threw away half the code due to a change in the (still young) UI design. We eventually shipped the rewritten and redesigned Add-ons Manager in Firefox 4. By this stage, the Wiki page containing the notes from our weekly meetings was so long that it often took several minutes to load. And sometime during that adventure, Dave made me a peer for the Add-ons Manager module. I say "sometime" because I don't actually recall him ever telling me.

Fast forward to a few months ago, where I got the chance to break a third of all the unit tests for the Add-ons Manager. Okay, maybe that part wasn't so fun... but solving the add-on compatibility problem was.

Apparently that (and everything else) went well, because then this happened:

Dave: Hey, so, wanna be module owner?
Me: Yea, sure.
Dave: Oh... I expected to have to convince you.

_{(Note: A mostly accurate summary, not an exact transcription.)}

So here I am, (sub-)module owner of the Add-ons Manager. It even says so on a wiki, so it must be true!

So what's this mean? Mostly it means more work for me - and certainly new challenges, which is partly why I so readily said yes. I've been thinking more and more about direction, code quality, and solving problems in the "hard" to "impossible" range - but that'll come in a later blog post. For now, it's business as usual. And I'm in the business of kicking ass fixing bugs.

Related posts:

1. Add-ons Manager API: Change in event order when restartless extensions are installed
2. Solving Firefox’s add-on compatibility problem
3. Status update: Extension Manager UI, Tab matches in Awesomebar

This makes me sad. And it's a problem that's been magnified by the switch to rapid release. One of the strengths of Firefox is it's rich selection of add-ons. In fact, 85% of Firefox users have chosen to install an add-on. On average, those users have 5 add-ons installed. Firefox users really love their add-ons. So it's not surprising that they get frustrated when one of their favorite add-ons gets disabled because it's not marked as being compatible with the new Firefox update they just installed.

So I started working on a project to fix it. The end result will be that most add-ons will automatically be compatible with Firefox, starting with (hopefully) Firefox 10.

At the time of writing this, I've not yet finished the project. There are parts described below that I haven't completed yet. But it's progressed far enough to safely enable the new behavior on Nightly builds, starting with today's Nightly build (labelled 2011-11-18).

Many of the changes are also on Aurora, but disabled. If you want to test the new behavior, go into about:config and change the extensions.strictCompatibility preference to false (true to re-enable the old compatibility behavior). Once I have a couple more major bugs fixed, we'll make the call on whether to enable the new behavior by default on Aurora (which will ultimately become Firefox 10).

How does this work? The gritty details.

The problem with incompatible add-ons is that most of them are actually compatible - they just don't know it. Unfortunately, blindly enabling all add-ons will enable some that are really are just incompatible, which will end in something breaking. So we needed a way to detect which add-ons would most likely be affected by incompatible changes to new versions of Firefox.

Assuming the extensions.strictCompatibility preference is set to false, add-ons will use the new compatible-by-default behavior. However, there are several reasons the Add-ons Manager will revert to using the old method of strict compatibility checking for a given add-on:

• The add-on author chose to opt-in to strict compatibility checking by adding <em:strictCompatibility>true</em:strictCompatibility> to the add-on's install.rdf
• The add-on has been tested and determined to not be compatible with that version of Firefox (the Add-ons Manager gets this information from AMO)
• The add-on uses a binary component
• The add-on hasn't been updated in an extremely long time (the compatibility data needs to state that it is at least compatible with Firefox 4, or Toolkit 2.0)
• The add-on declares that is it only compatible with future versions of Firefox (we assume that add-ons are not backwards-compatible)

In the future, we also hope to give Firefox the ability to do a series self-tests to determine whether an add-on has broken something, and automatically mark that add-on as incompatible. Additionally, if the above heuristics end up producing false-positives, we may add the ability for AMO to tell the Add-ons Manager that it's heuristics are wrong for a given add-on.

This also required a change to the way add-on updates are handled. Previously, users that disabled add-on compatibility checking didn't get updated to the most recent version of their incompatible add-ons, since those updates often weren't compatible with their version of Firefox (even thought they explicitly disabled compatibility checking). This meant that those users (which included most users running Nightly builds) didn't automatically get important security updates of all their add-ons. The changes needed for the compatible-by-default behavior made it easy to support updating incompatible add-ons even for users that disabled compatibility checking, which means they'll be running a more up-to-date and secure browser.

Finally, I should note that making add-ons compatible by default does not mean that add-on authors should stop including compatibility data, or stop updating it. Older versions of Firefox still rely on the compatibility data, and users can choose to opt-in to strict compatibility checking. Furthermore, add-ons need to still declare compatibility with at least Firefox 4 (or Toolkit 2.0).

----
Gmail Archive Ukraine translation here - http://www.stoodio.org/archive-solving-firefoxs-add-on-compatibility-problem.

Related posts:

1. The Add-ons Manager and I are rather good chums
2. Add-ons Manager API: Change in event order when restartless extensions are installed
3. Status update: Extension Manager UI, Tab matches in Awesomebar

4 Rules:

1. Link to your original tagger(s) and list these rules in your post.
2. Share seven facts about yourself in the post.
3. Tag seven people at the end of your post by leaving their names and the links to their blogs.
4. Let them know they’ve been tagged.

7 Things:

1. I have two pet sharks - a silver shark and a rainbow shark. They live in two freshwater tropical aquariums along with angel fish, tiger barbs, neon tetras, bleeding-heart tetras, upside-down catfish, bristle-nose catfish, black-line flying-foxes, algae eaters, apple snails, black ghost knife-fish, a skunk loach, and a plecostomus.
2. I'm acrophobic. This isn't vertigo or not liking heights. This is full-blown irrational extreme fear. Panic attacks, complete disorientation, uncontrollable shaking, visual and auditory hallucinations, physically ill, vomiting, and losing consciousness. Getting up to the 3rd step of a step ladder is a huge accomplishment for me.
3. I'm co-founder of the Dunedin Makerspace, which was established in late 2010. We do both hardware and software, and I organise the software-related talks for every second Thursday night. My current project there on Saturday afternoons is building a 3D printer.
4. My online nickname, Unfocused, has no deep meaning. Some people read too much into it, but "Unfocused" was just a synonym for "Blur", a nickname I originally gained offline. When I was around 9 years old, my classmates thought it would be funny to mispronounce Blair as Blur. It stuck.
5. I am the southern-most Mozillian (AFAIK). I live in Dunedin, which is 45° 52′ 0″ S.
6. I can't drive. I never learned to drive a car. It's not that I've never had the chance - I just don't want to learn to drive.
7. I hate timezones. Seriously. They suck.

7 People:

1. @peregrinogris
2. @geoff_lankow
3. @nigelbabu
4. @whimboo
5. @felipc
6. @2braids
7. @heycam

No related posts.

There's a bunch of Kiwis out there that like Mozilla. You're Mozillians - whether you work at Mozilla, file bugs, or just tell your mates about Firefox. But not all of you know one another. About time we changed that.

Now have a mailing list just for the Mozilla NZ community! Subscribe via Mailman or Google Groups. And to post a message, just email it to community-newzealand@lists.mozilla.org.

The list is for anything vaguely related to Mozilla and it's mission in NZ. So that's stuff like making sure "colour" doesn't get a red squiggly underline when posting to GeekZone, promoting the open web at WebStock, localising Firefox in Māori, or making sure TradeMe works.... you know, for work (yeah right).

Oh yea, and the Aussies have a mailing list too, but it's not as good.

No related posts.

Status

• Met with Limi to discuss design details, including:
  • BarTab-like functionality
  • Single-instance vs traditional tab-like behavior (preferring this)
  • Adding/removing AppTabs - dragging & context menu
  • Opening normal tabs when attempting a navigation action in an AppTab
  • Displaying less chrome when in an AppTab (and how awkward this will look for tabs-on-bottom)
• Patch close to ready for foundation work
  • Had some fun with using yield for async tests
  • Learnt more about nsSessionStore than I wanted
  • Some debate over whether this implementation is the right approach (see bug 563730)

Loose ends

• Need to resolve whether to keep current implementation approach or start over

Next steps

• Finish and land foundation work in bug 563730
• Delve into adding some meat
  • Context menu
  • UI for adding AppTabs
  • Remembering added AppTabs
  • BarTab-like functionality
  • etc

Target for next week

• Resolve implementation debate
• Fix review comments, or start alternate implementation

Extension Manager UI Redesign

Status

• Some reviews done
• Mocking provider planning and implementation (not there yet)

Loose ends

• None

Next steps

• Mocking provider + tests
• Fix top priority bugs

Target for next week

• More work on mocking provider
• P1 and P2 bugs as time permits, eg:
  • Bug 567127 - Add Install button for installing from local file
  • Bug 565682 - Support Drag & drop of XPI file
  • Bug 562890 - Add preferences button in list view

Miscellaneous

• I'll be in the Mountain View office during the week of 28th June

Reflections

• I still get too stressed by certain things that are unavoidable when being a software developer

Related posts:

1. Status update: Extension Manager UI Redesign
2. Status update: Extension Manager UI, App Tabs
3. Status update: Extension Manager UI, Tab matches in Awesomebar

Status

• Landed! Woo!
• Backed out! Boo! Thanks to a Ts regression on OS X 10.5.8, which turned out to be bug 519893 again.
  • A little background: A specific OS function in OS X sometimes takes significantly longer if there is no monitor attached. So IT adds resistors to the monitor port of the Mac Minis that run Talos, to trick OS X into believing there is a monitor plugged in. Yes, this really is as ridiculous as it sounds.
• Successful test day on April 30th (Henrik did an awesome job, over a 16-hour day)
  • Plenty of bugs found, but no show-stoppers. Some were known, others not. (And yes, finding bugs is a good thing.)
  • Also got a lot of feedback on the UI design
  • Test days mean a LOT of bugmail

Loose ends

• Mossop will be re-landing soon

Next steps

• Fix some annoying low-hanging fruit like bug 554237
• Implement manual updates pane (bug 562622)

Target for next week

• This is temporarily low-priority for me, while I get stuck in on starting App Tabs (see below). So I'm not expecting to get a lot done here, sans any reviews that may come up from people submitting patches (hint hint).

App Tabs and Home Tab

Status

• Picked up this project, together with Marco
  • Marco will be working on the Home Tab (a locally hosted home page that sits in a special App Tab)
  • I'll be working on App Tabs (small persistent tabs that show a often-used specific site/page, and don't get lost in all your other tabs)
• Looked to see if any addon has this implemented in a way that could be uplifted, but didn't find anything suitable
• Started working on a proof-of-concept
  • Hit various roadblocks and discovered its going to be more work than originally anticipated
  • Tabbrowser makes certain assumptions everywhere that I need to burn with fire correct
  • Hoping that once the foundation is set, everything else can be separate bugs. eg: syncing between windows, make the documents single-instance, etc

  

Loose ends

• None

Next steps

• Finish foundation work in tabbrowser

Target for next week

• Want to at least get the basic stuff working properly. Not sure whether that will include review-ready code or not (sadly, probably not)

Reflections

• Regardless of how exciting an existing project is, starting a new project always seems somehow more exciting

No related posts.

Status

• Fixed a bunch of bugs QA found, and the important remaining P1 bugs blocking landing - including:
  • Supporting external/instant installs (ie, those without an AddonInstall object)
  • Showing the correct status when enabling/disabling lightweight themes
  • Updating addon state changes and showing a restart notification in detail view
• Pretty much everything has been reviewed now - only small changes came out of reviews (feels great when something comes together neatly like that!)
• Was *almost* ready to land on Friday - so close! Fingers crossed for Monday/Tuesday. Things that got in the way:
  • Sickness (not me this time) and holiday
  • A couple of small outstanding reviews
  • Worries about breaking mobile, which was about to branch
• Boriss showed off a more awesome manual update process (has a really nice feel to its flow, yet it still allows for more flexibility)
• The Discovery pane has been unofficially renamed the Disco pane

Loose ends

• None

Next steps

• Land it already, gah!
• Fix the things we broke by landing it
• Further stabilization and polish
• Manual update process

Target for next week

• Landing and damage control
• High priority bugs - I'll be re-triaging this week
• Start on new manual update process

Reflections

• Continually having to push back landing dates is frustrating
• We still need to get more familiar with working on project branches
• The scent of a new project really gets my mind racing

No related posts.

Extension Manager UI Redesign

Status

• Missed the date we wanted to ideally get this landed on trunk (31st March) - this was disappointing, but there was just too much to get done (including reviews, as always). On the upside, we want it to bake in nightlies for awhile before being pushed out in an alpha.
• Almost done the first round of reviews - feedback was mostly lots of small stuff, which is positive.
• Lots of bugs fixed! Mostly a lot of little stuff. The QA guys are helping hugely.
• Made it look prettier with icons from Boriss and some CSS work (NOTE: THIS IS NOT THE FINAL LOOK!)

Loose ends

• None.

Next steps

• Land on trunk.
• Fix more bugs, and add planned features (including start of AMO integration).

Target for next week

• Next round of reviews.
• Fix remaining P1 bugs blocking landing.
• Assuming this all goes smoothly and the API is ready to too, we can land it on trunk (!!)

Tab matches in Awesomebar

Status

• Landed on trunk! (Finally!) It's in nightlies and will be in Alpha 4.
• There have been some reports of people liking it.
• Anthony Hughes from QA held a test day on 9th April. I missed most of this due to timezone differences, but it seemed to go really well - with a few minor bugs discovered.

Next steps

• Write a blog post.
• Various followup bugs to fix.

Miscellaneous

• I'm currently reading Everything is Miscellaneous. Highly recommended - it's about information and digital knowledge.

Reflections

• I should know better than to overwork myself and get burnt out.
• Books are awesome.
• Hackers around the world are selling their soul for a certain new device that is the start of a computing future they do not want. This saddens me.

No related posts.