Windows Build Prerequisites change

If your building from source on Windows, then it will come as the most un-welcomed surprise (well, I have been told it's been there for a while) that you now need the Window's Vista SDK to do a build. The exact reason why escapes me at the moment. Something about terrorists winning if we don't.

Makefile.in Madness

I tend to really hate doing Makefile.in files because they are just copied from somewhere and they sometimes don't have everything you need. And when you don't know what your doing, that can screw you up. I created a generic Makefile.in file that is usable for extensions, idl interfaces, and C++/javascript components. It's also documented as much as I could find information on it. Just uncomment what you don't need and delete the rest. I covered as much as I could, I might not have covered every single option, but I think I got most of them.

You can also use Ted Mielczarek's Javascript Component Wizard. I dislike using wizards, but to each his own.

If you want to repay me, you can add me to the contributor's list (Cesar Oliveira) for the Makefile.in.

Building OpenKomodo

I use OpenKomodo on windows all the time. It is a nice IDE for javascript and detects formats that you use in Mozilla development like .idl and .xul. The only bad thing about it is that it has a lot of Mozilla 1.8 (Firefox 2) memory problems. You can go over 700 megabytes just by doing nothing.

I wanted to have it here on my Linux box, but they do not offer a 64bit version of OpenKomodo. But because they released it late last year, I can build it. The experience was a little... refreshing. Reminded me of building Firefox for the first time.

If you can build Firefox, you should be able to build Komodo. The steps to build are outlined on their svn's README.txt. I'll have to hand it to them for getting something out in 3 months :)

There are a few things that I stumbled on when doing this that I will note here :

• There build searches for your distro. I got an error :
  platinfo.InternalError: Could not determine distro & release from first line of
  '/etc/bluewhite64-version' (Bluewhite64 12.0.0).
  I had to add "Bluewhite64": re.compile("^Bluewhite64 ([\d\.]+)"), to line 583 of util/platinfo.py and later src/release/codeintel/support/platinfo.py.
  


• I had to build python because they only offered the x86 binary. Two mistakes I made were trying to have it find python on my system and symbolic linking python. At one point during the install, something was taking a lot of time and disk was spinning like crazy. I stopped and looked and it was copying everything in /usr to some other directory. A time consuming process indeed.
  To solve this, I :
  
  
  
  1. got python 2.5 source
  2. created a folder in my home directory called root: mkdir $HOME/root
  3. untarred and configured python with --prefix $HOME/root and --enable-shared
  4. compiled. Then I went to $HOME/root and zipped up the contents : zip -r linux-x86_64.zip .
  5. Copied linux-x86_64.zip to mozilla/prebuilt/python-2.5/
  
  


• Undefined reference to X...., was a already patched but not committed bug.


• There is something in linux-x86.zip python binary that isn't in the linux-x86_64.zip binary we created. Had to unzip lib/python2.5/site-packages/activestate.py from linux-x86.zip and copy it to build/cvs1.8-ko4.3/mozilla/ko-rel-gtk2-ns-shared-tools/dist/python/lib/python2.5/site-packages/


• I had to explicitly say the version : bk configure -V 4.3.0-devel

I hope this is useful for anyone else who wants to build it.

yay, incompetence

So I have started doing XPCShell tests as part of my next release. This has been giving me a lot of trouble, and not because tests are failing, but because my components and interfaces weren't being registered to XPCShell's liking (the component works fine in Firefox). Today I find, it was because of my incompetence.

When I exit XPCShell, I got the following message (XPCShell prints its error message when you quit on Windows, unless you call the quit() function).

JS Component Loader: ERROR file:///c:/builds/firefox-debug/mozilla/mozobj/dist/bin/modules/XPCOMUtils.jsm:115
TypeError: i is undefined

This is particularly tricky because it looks like its an XPCOMUtils.jsm error, when in fact it isn't. The mostly likely reason is that a component is trying to use an interface it cannot find, and therefore the component fails to register. But why can't it find it? I checked XPCShell and got the expected message :

js> print(Components.interfaces.nsIWindowsRegistryService)
undefined

After asking in #developers (twice) thinking that I need to add an EXPORT line to Makefile.in. Waldo pointed me to Javascript HTTP server code in netwerk/test/httpserver/Makefile.in. I compared Makefiles, and noticed one thing that may be causing my problem :

46 MODULE = test_necko

I kept everything under one module (grouppolicy). The tests being in the same module as the extension seemed like one rational reason why my code was working in Firefox but not in XPCShell, so I changed by module from grouppolicy to test_grouppolicy.

And holy **** did it work.

js> print(Components.interfaces.nsIWindowsRegistryService)
nsIWindowsRegistryService

I was a little disappointed that I had to spend two days on such a simple mistake. But I was happy enough that I stopped working to start this blog post. But it made me think about how little I know about what I'm doing sometimes, because we copy and paste a lot of things (Makefile.in, install.rdf). And naturally, when something goes wrong we don't know what to do. In fact, I don't know what a lot of lines in a typical Makefile.in do. But it is mistakes like these that help you learn.

Getting this done, one policy at a time

So while the bug has been posted, I wanted to go into more details about the policies that have been implemented so far. The complete list is on a google spreadsheet, but I will outline some of them :

Apologies to the smaller images. You can click most of them for full resolution.

• Enforce Full Screen : Some people have been asking for this, for a kiosk setting. This looks identical to IE7 (it's not full-screen by default). The navigation toolbar, bookmarks toolbar, and menu are all gone along with the status bar.
  


• Disable changing the home page : As you'd expect.
  


• Disable closing the browser and Explorer windows : This is pretty funny, neither File->close nor alt-f4 work. Interestingly, IE7 throws an alert box if you try closing it from the task manager, but your prompted a few seconds later with a dialog box telling you that the application isn't responding and whether you want to force quit. The force quit works. Firefox3 does almost the same thing, but doesn't throw an alert box.


• Disable Context Menu : Disables right-click context menu on web pages


• Hide Favorites menu : I don't know why you would want to do this, but it's a policy.
  


• Turn off displaying the Internet Explorer Help Menu : Really folks, wtf?


• Turn off tabbed browsing : This makes some people sad. If you set the policy after creating tabs and saving the session, the tabs still appear. So still some bugs :)


• Proxy Settings : Yay, my part. I guarantee it works or your money back! Here I am connected to a Japanese proxy server and went to google.com
  

The achilles' heel in my entire project right now is about:config and chrome://. But we can settle that eventually. Right now, the project needs a lot of code polish and tests.

Release

Yes, at around 4:20 in the morning, bug 267888 got a long awaited response. Well, actually it was the first comment in over a year for that bug, so a toast to that!

This release is about getting community feedback, and hopefully get a dialog going. Best case scenario is that people tell me to keep going and aim for Firefox4 or something. Worst case, I get nothing, and that's bottom of the barrel. But I have hopes that people will say something (probably to disagree verbosely against generic IE policies).

Next for the extension is a lot of code cleanup. There are several areas where it is difficult to read, or it's not apparent what's happening.
There also needs to be tests. Maybe some reftests? A requirement if people want this in the codebase.

Time for sleep.

FUELing the fire

While doing some work on updating one of the policies to use FUEL, I hit upon a bug in the library. While I wasn't in the mood to patch (it is a trivial fix), I thought this would be a great opportunity to try some Mochitests.

Previously I discussed adding js components to make getting registry values easier, it would nice to have some tests in the process.

I actually rarely do tests actually. I shy away from them for several reasons, but I want to try and turn around this bad habit. I strongly dislike doing manual tests, because if something goes wrong and you get a fix, you have to make sure nothing else broke in the process. Thankfully, Mozilla offers some choice in doing your tests.

Starting Mochitest was acutally a problem. All your tests and utilities are in mozobj/_tests/testing/mochitest/. You must be in that directory when running the mochitests. The tricky bit seems to finding where exactly your tests are. There seems to be a few possiblities:

browser/*
chrome/*
tests/*

The directory structure follows the tree. For example, since FUEL's tests are in mozilla/browser/fuel/test/, the path to fuel's chrome tests (if it had any) would be in chrome/browser/fuel/test/.
The script running the tests is a perl script called runtests.pl. Depending on the parameters, it looks in different places

--chrome is the chrome/* directory
--browser-chrome is the browser/* directory
nothing is the tests/* directory

You can pass the --test-path=browser/fuel/test/some_test.html to do one unit test, or test the entire directory by doing --test-path=browser/fuel/test/ --auto-run. If you leave --test-path=... out, it will test everything. Since my code is in browser/, I did the following command :

perl runtests.pl --browser-chrome --test-path=browser/fuel/test/ --autorun

Predictably, it passed. That's because it wasn't testing a certain condition. I submitted a test case with the bug. I still know very little about how to create a Mochitest, but how to run the tests was just as important as the testcase itself. So in that sense, I am happy with the results.

Inspirational link