Tuesday, October 18, 2011

Getting Thunderbird to work with distribution.ini

The bug I'm working on is the ability to customize vanilla Thunderbird with a group of settings (through distribution.ini). For those who do not know, Thunderbird is Mozilla's open source mail client. (Mozilla = makers of Firefox). I'm far from done. This entry is a culmination of what I have learned so far.

Checkout the repo

I am working with Fedora, so I use yum. I followed the build and configure instructions from here. In a nutshell, here are the steps to cloning the comm-central
(Thunderbird) repo:

1) yum install mercurial - to get Mercurial, a version control tool.

2) Create a file called ".hgrc" in your home directory and put these in it:

username=Firstname Lastname



Note: Obviously, replace Firstname, Lastname, and my.email... with your information.

3) Make sure you're in the directory that you want to put the repo in (for example, your home dir) then checkout the repo:
hg clone
http://hg.mozilla.org/comm-central/ src-thunderbird

So now you should have a "src-thunderbird" folder in your current directory.

Building Thunderbird

1) Go to your src-thunderbird directory (cd src-thunderbird).

2) Create a .mozconfig file. (I use vi, so vi .mozconfig). This file will contain your build configurations for Thunderbird. The contents of mine are:

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-tbdebug

ac_add_options --enable-application=mail

ac_add_options --enable-debug

ac_add_options --disable-optimize

"obj-tbdebug" is the directory where all my object files will end up (you can change what you call yours). I will refer to this as objdir, from now on. The second line says, build me Thunderbird. The third line is because I need debugging printouts. The fourth line I just threw in for good measure. You can read more about configuration options here.

3) Build Thunderbird! "make -f client.mk build" (while still in src-thunderbird). This step will take a while (more than a half hour in my case).

4) Once the build is done, run Thunderbird with ./objdir/mozilla/dist/bin/thunderbird. Since we configured this build with the debug option, you will see a lot of printouts at your terminal.

Updating the repository

Make sure you're in the src-thunderbird directory. On the terminal, execute python client.py checkout. Re-build again.

Modifying the source files

The source files are everything outside your src-thunderbird file. Everything in it are your object files. When you modify your source files, you need to re-create your object files. You can run make -f client.mk build again (in your src-thunderbird dir), and it won't take as long as the first time.

If you changed files in only one directory, you can re-make only that directory. For example, if you changed files only in ~/src-thunderbird/mail/components, run make -C objdir/mail/components.

Getting distribution.ini working

1) This is a sample distribution.ini. This file must be placed in objdir/mozilla/dist/bin/distribution.

2) Add "distribution.js \" to the EXTRA_JS_MODULES section of Makefile.in (which resides in ~/src-thunderbird/mail/base/modules).

3) distribution.js should be in ~/src-thunderbird/mail/base/modules. I copied and modified the Firefox version. (Code referring to bookmarks and livemarks were ripped out.) I also changed the name of the object it exported to something like TBDistCustomizer.

(Note: JS modules have EXPORTED_SYMBOLS at the start of the file. This is as opposed to components files (which are also JS), which do not.)

cd to objdir/mail/base/modules and type "make".

5) Modify mailGlue.js (in ~/src-thunderbird/mail/components) so that:

(a) It would import distribution.js (Components.utils.import("resource:///modules/distribution.js");); and

(b) it would create an instance of TBDistCustomizer. This intance can now be used to call the code in distribution.js that actually changes prefs (applyPrefDefaults).

Hitting the brick wall

So now I've come to the point where preferences set in distribution.ini are being set in Thunderbird, but there is a catch: some prefs are set properly, while others are duplicated. For example, mail.phishing.detection.enabled is set correctly, but something like network.cookie.lifetimePolicy instead becomes duplicated, with one version having the default and the other having the value that was set in distribution.ini.

I am still trying to figure out why this is so...

Climbing the brick wall

The problem was that distribution.ini doesn't like spaces around the "=" sign. network.cookie.lifetimePolicy = 1 should be network.cookie.lifetimePolicy=1.

Thanks to...

The MailDev team at Mozilla! In particular Standard8 and sid0 for helping me get started.

Wednesday, June 15, 2011

Mozilla XPCom

Here is the link to a list of ALL the XPCOM contract ID's/components and interfaces are: http://www.oxymoronical.com/experiments/xpcomref/

I am currently working on creating an addon that will always take settings from Internet Explorer and set the same prefs for Firefox. Still in the research stages, tho.

Tuesday, May 24, 2011


I feel powerful executing the above command as a sysadmin 3=) While practicing on my own database for DBA625, I happened to close a session after thinking that zenit has once again frozen. As it turns out, closing session doesn't necessarily end all processes in my database. When I tried logging on again, I got this:

SQL> connect sys as sysdba
Enter password:
Connected to an idle instance.
SQL> startup
ORA-01012: not logged on
SQL> startup mount;
ORA-01012: not logged on

After some googling and deciding that I do not want to mess with resetting memory sizes, I came across "SHUTDOWN ABORT;" and it fixed all my problems.

ORACLE instance shut down.
ORACLE instance started.

Total System Global Area 631914496 bytes
Fixed Size 1338364 bytes
Variable Size 440402948 bytes
Database Buffers 184549376 bytes
Redo Buffers 5623808 bytes
Database mounted.
Database opened.

Thursday, April 7, 2011

Lessons in creating Firefox Enterprise

Firefox Enterprise

For the past 6 months, I have been at CDOT as Mike Hoye's cronie, and along with scott and annasob, I have been working towards creating an enterprise version of Mozilla's Firefox. Bespoke IO, mhoye's company, will be selling the software that lets administrators customize Firefox and produces the MSI that makes deployment across a network easier. It will also be offering Sync services. If you are not familiar with that, Sync lets you store your browsing history in a server--your own or Mozilla's--so that you can you can access your browsing history, passwords, and bookmarks across several different devices. I will leave the elevator pitch for the boss.

As far as I know, an enterprise version of Firefox conflicts with Mozilla's philosophies about freedom on the web. (To illustrate what "freedom on the web" means, an example: if a user wants to watch a video on YouTube, s/he should just be able to click on a link and the video will play instead of being told that s/he needs a plugin.) That is why Mozilla has not produced the product themselves, and an opportunity for my co-op position was available.

Since Mozilla is open source, it was a matter of taking the existing Build Your Own Browser code and customizing it (with a lot of guidance from kev and lorchard!). The first screenshot is what our BYOB was near the beginning of the project. The first thing I added was the Homepage tab. The second screenshot is what the latest version looks like. The administrator can now choose to lock some things, like the homepage, proxy settings, and which updates are allowed.

Wading through code

It was a mess :s As mhoye put it, he threw me under a bus. Although the framework BYOB was built on was documented (Kohana), for me, there was no way to actually understand what was happening in BYOB unless I did a million printouts and walkthroughs. I realized only much later that the code was exactly what they taught Seneca students in the SYS courses. You have your views, controllers, and models, and then the database.

mhoye had me started on letting an admin choose what the homepage was. Where do I begin? My coding bff since then has been the Multi-file Search option in Textwrangler. I searched for all instances of General, then Locales, then Collections in the hopes that I could trace what happened whenever these words popped up. The problem was that General was useless and Locales was coded differently from little prefs like homepage and proxy settings.

Luckily, kev and lorchard were kind enough to point me in the right direction. But then, it was like giving me a clue as opposed to telling me exactly what to do, which was better in the end. Teach a man how to fish and all that.

Since then, I have gotten to know BYOB really well, but I still learn something everyday, whether it's coding in PHP or bits of Firefox itself. (I dabble in Python every other month, too, but I avoid that part of the code as much as possible.) So far, I can lock down the homepage, proxy settings, and updates. End users cannot change them. Administrators can also add certificates and specify what server they want to use with Sync (if they want it to be used at all).


Mozilla's goal is to give the user the best web experience possible; mine is to cramp the user's style just a little bit.

The last great roadblock I had was both a coding problem and a Firefox issue: how do I get BYOB to upload certificates and then add them to the list of certificates in Firefox right from the beginning?

The frustrating thing about coding with Kohana was that I didn't grasp the idea of routes right away. There is a special file in the framework that says, if your url is like this: http://myapp.com/fnName/randomText/moreRandom/, then you should be accessing the first file with function fnName in it (there could be more than one!), and pass it the "*[Rr]andom*" arguments.

I also came up with what I believe to be a rather inelegant solution to adding certificates to Firefox... only to find out that unless I find a way to make the certificate window read-only/disappear, a user can delete any certificate in it. That's problem # 2.

Problem # 1 is bookmarks. Adding bookmarks to a Firefox build was something that Moz's BYOB already did, but how do I lock those bookmarks so that users can't delete them? I know of places.sqlite, bookmarks.html,and the bookmarkbackups folder... But how do I fiddle with those three so that my bookmarks can't be deleted? Right now, I can create a file with json-formatted bookmarks data in it and name it so that Firefox will always load those bookmarks when the browser starts. But that prevents any bookmarks the user will add from loading. Not very user-friendly.

Problem # 3 is preventing the user from deleting addons. Right now, addons are locked so that a user can disable them, but not delete them. From the reading I've done, there is a file called userChrome.css that I can write myself; it prevents the addon manager from appearing at all. I could insert that file into the depths of the Firefox application directory. Is there a better way?

What's next?

Sometime in the summer semester, I believe mhoye is looking for beta testers, so a deadline is tentatively set. My goal for the next week is to leave some good documentation (so that I don't curse myself when I come back from the semester break) and get the bookmarks locked. Still not sure what to do... If you have any answers, please share :D