Thunderbird Multi-touch 0.1 Release – on the path of a bug

Here lies my first release submission towards an open source problem.  The problem in this Thunderbird Email Bug is actually an enhancement, and not a problem with the software.  This solution is providing the necessary programming to migrate current multi-touch trackpad controls for the Mac, which are currently working in Mozilla’s Firefox, and move them into Mozilla’s Thunderbird email program.  This made for an ideal project for my open source course as I happen to use a MacBook Pro for my programming courses and it has a multi-touch trackpad on it.

The goal of this bug is to implement a default behaviour for multi-touch trackpad events and enable those behaviours to be extendable for extension developers.  The general steps of this… get some basic functionality in place, then get a framework developed for its extensibility and finally develop an extension that alters the behaviour thereby proving that this extension usability works.

The first code changes

Here was the easy part (don’t worry, it didn’t last long).  On the Bugzilla page for this problem, there had already been some community dialogue around what the problem is and a proposed first step of copying out code from Firefox and placing it into Thunderbirds files.  The commentary even showed what needed to be moved and where to put it.  Great!

So I move the code, starting getting some first glances at the code base for Thunderbird and compiled it for the first time with a slew of code changes in place… failed!  The program wouldn’t run properly.  There was something breaking it.  So I spent a pile of time resolving this by commenting out chunks of the code that I had put in place.  Next, now that the program was running, I needed to resolve why none of the event handling was producing any results.

Standard error output

Along the way, I learned how to launch my compiled version of Thunderbird so that I could see the debug information displayed to the console.

$ /Users/andrew/mozilla-commsrc/obj-tb-dbg/mozilla/dist/ShredderDebug.app/
       Contents/MacOS/thunderbird-bin  -profilemanager

My next step was to figure out how to print tracking output text to the console, which I also discovered by using a built-in javascript function that serves this purpose called dump( ).  Now I was able to follow the initialization of the multi-touch event handler object, and track along as events were triggered. This allowed me to identify explicitly how to isolate out and purposely trigger commands for the functionality noted below.

Creating Functionality

Now it was time to get this all working.  As per the bug, I was to endeavor to get a 3-finger scroll up/down/left/right to do something specific.

UP:  scroll to the top of the window

DOWN: scroll to the bottom of the window

LEFT: go to a previous email in the message thread

RIGHT: go to the next email in the message thread

It seemed obvious to me at this stage in the game that this functionality wasn’t going to work the same was as it did in Firefox due to the different code base.  I did manage to find a file in the Thunderbird code base that, looking at the name of it now, seems quite obvious that it would have an answer.  There I found some function calls and their related command string that would create the movement through the messages.

mail3PaneWindowCommands.js

Next was my adventure in trying to get some code snippets that would cause the scrollTop and scrollBottom  events to happen.  There was nothing that I could identify in the Thunderbird code itself that would cause this to work.  I finally resolved to look back at the code that I had commented out or erased that was originally part of the Firefox solution.  I found a function call that seemed to drive these events for it, but they’d do nothing when activated in the Thunderbird build.

globalOverlay.js

It wasn’t until my Open Source class where I presented my dilemma to the class and my instructor, David Humphrey mentioned something that triggered my thinking to look for a solution by doing something I had previously abandoned.  Looking back, it was a pretty simple fix, I included the javascript file that had the function so that the event handling code would be able to trigger it properly.  This magic file which was key to getting things working was in the toolkit bundle of files which was explained to me as a set of files that were used amongst the many Mozilla applications.  This made complete sense.  The scrolling window events are something that are shared amongst all the software programs for Mozilla.

However, it was not a complete solution.  I placed some logging code in the other file to prove that this function in the other file was in fact working, and also proved that there was no reason for the function not to be working.  My next thought had to do with focus()…. Mozilla had a single window to focus on, Thunderbird had a single window with 3 panes in it.  Were the multiple panes causing focus problems?

3 Panes in the window!

Now I started searching for previous usage of code that had something to do with focusing the window, more precisely, focusing the panes.  I searched and I searched and I searched, and finally resolved to try something simple.  Something that was indicative of a 0.1 release, simple and un-comprehensive.

window._content.focus();

Why was this a problem in my eyes, even though it was the trigger that made it finally work.  It my simple opinion, if you scrolled up or down, it always affected the pane that displayed the email.  If you scrolled left or right it always impacted the message selection in the thread of emails.  It didn’t matter which pane you were hovering over, it always affected the same items in the window.  This seemed erroneous because I was hoping to isolate each pane to land a scrolling action for each pane… at the very least, isolate out the list of email folders for the pane on the left hand side.  There are two reasons why my interest in accomplishing this more defined implementation was wrong: 1. because it is my own idea and not an item of consensus or discussion by the Mozilla community, 2. because it adds unnecessary work to a 0.1 release.

Items to be improved

Considering this is my first code piece submitted, it’ll be bound to be filled with incorrect coding practices in commenting, indentation, usage of functions, etc… So I’ll be very much looking forward to input from the community to help me identity areas of improvement so that as I endeavor on my next steps that I can improve the quality of my patch work.

Visit the bug and check out the patch yourself.