0.31 is now out!

So earlier today I was trying to think of a way to test our 0.3 release with a plugin that is actually hogging resources. Unfortunately since I was not able to create or find such a plugin I thought that perhaps lowering the amount of availble resources will do the trick. I already had a VM running Fedora 7 set up and figured this would be a good opportunity to also test our code in Linux.

So I fired up the VM, booted into Fedora, checked out a clean tree, applied the 0.3 patch and built it... then I spent about half a day trying to install Flash 9 on minefield since none of the automated installers would work. I finally managed to install it only to find out that our code wasn't even getting executed.

I spent all night trying to figure this out and thankfully after going through a lot of files I managed to make it work. I'm therefore releasing PluginWatcher 0.31 which now works on Windows and Linux. I don't own a Mac but I believe it should work fine on OSX as well.

Something to note before trying 0.31 out... it seems that plugins work differently on the different operating systems. The runtime pattern of the same flash game seems to be different when executed on the different platforms. I'm not really sure why this is the case but it seems possible (even likely) that this is due to some fundamental difference between the two operating systems.

If you tried our old patch on a Windows machine please continue using it as there are no changes in the new patch that are applicable to you. If you are you using Linux (or OSX) and would like to try out our new patch please visit our wiki project page!

My contribs

My small contributions to other projects:

* I did a translation of ISOMaster into Hebrew for Andrew (andrew).
* I tried Canvas3D on my machine at home for Cathy (cathy).
* I'm currently in the process of trying out the metrics extension for Simon (SimonJ)

You can download the current Hebrew ISOMaster .po file here.

For Cathy's contribution I tested Canvas3D on my home machine with the following spec:

Asus P5ND2 Sli-Deluxe
Pentium 4 CPU
nVidia GeForce 6600 GPU (256Mb)

Unfortunately I was not able to see the graphics on my machine.

I'm done building the the metrics extension for SimonJ and unfortunately it doesn't seem to work at its current state

0.3 Released (Finally)

So me and Brandon had finally finished our 0.3 release today. It's been quiet the journey as we have had to deal with so many different issues... most of which really had nothing to do with our code or even the hairy Mozilla code surrounding it. Our largest obstacles were indeed related to the tools we were using and the build system which seemed to dislike code edited by the Visual Studio text editor while working just fine when the code was edited in a different app. Its amazing how depressed you can become when nothing seems to be working for you. Luckily though we did not give up and despite the many struggles, both I and Brandon feel like we have prevailed and actually came up with some pretty interesting code.

From a technical point, one of our biggest challenges was to find a way to communicate with the UI from deep within the plugin related C++ code. One of the problems we encountered with the C++ code itself was that it was in the form of a macro and that made it very difficult to manipulate. That meant that keeping track of anything across the different runs of the macro was basically impossible (since it involved referencing an external object in a macro that was getting called in numerous locations in other files). The need to communicate with the UI was initially for the purpose of notifying the user when a plugin was using too much runtime, however, once we figured out how to communicate with external JS code using Mozilla's observer services (many thanks go to mfinkle for that one) we realized that we can do everything we need directly from inside the JS code itself. So we simply made the C++ code report a plugin's runtime to the JS class, where the different statistics are tracked and the user gets notified under the right conditions. At the moment the user gets notified when a plugin has runtime x or above, y or more times in z amount of seconds.

In addition we also dump a line to the console every time a plugin has a runtime of one millisecond or longer.


The picture above shows console output and a notification bar advising the user about a plugin with a high runtime.

The picture above shows the console output when an interactive flash game is loaded.

So now that you know what our 0.3 does you can try it for yourself by going to our wiki project page.

And now for some final words about OSD. This course has not been easy, it was hard and confusing and very frequently frustrating, for both myself and Brandon. That being said I am glad I took it and I would do it again without hesitating because I got to meet some great people, got to see how people come together to form a community that in turn produces some really great stuff and got a chance to participate in solving a real world problem. The experience has been really invaluable and I thank Dave and Chris for pushing for this sort of education. Many thanks also go to all the people who helped us on our way here like Mark (mfinkle) who was always available for help on any topic, Robert (roc) who made Mozilla's code a little less hairy, Armen (armenzg) who helped us test our 0.1 release and of course Chris (ctyler) and Dave (dave) who were always super supportive and very flexible!

LXR/MXR

So I have played around with the Mozilla cross reference tools and found them to be very useful. The only issue I really had was that when you click on a link within the source code it performs a global search on that term and often times the results are out of context - especially when the term is a common member/method name within a number of different and unrelated classes. I have to admit though that searching for a specific function in the code (in my case the code that controls the refresh button) only made the work thats a head of me and Brandon seem even more daunting (though we are gaining new appreciation for large software as we go along). We already spent a couple of hours trying to figure out where our code would need to go and found some classes which we are hoping would come in useful - although by no means can we say that we have a clear grasp of how plugins operate within Firefox as of yet. We are meeting up this Wednesday to do some more digging and we are also going to be adding our own code, mainly some printfs to try and orientate ourselves within the source. Updates are to follow.

Firefox 3 built on Windows and Fedora (about 8 times faster)

So I have figured out what was my problem with building Firefox... as Ted Mielczarek pointed out I was changing the .mozconfig.mk file within the Mozilla directory thinking thats the configuration file when in fact it is actually .mozconfig without the .mk extension as .mozconfig.mk is auto generated by the build script (which would also explain why it was overwriting the file each time I ran the build command).

In any case I fixed that and then ran the build command once again. It started the build and after 9 very long hours (yes 9 hours) it told me that there were errors so it aborted the compilation. So what I did was create a new folder on my C drive then I re-downloaded the client.mk file and then checked out the code once again. I then created a .mozconfig file and placed it in the Mozilla directory and ran the build command. 10 long hours later the build was complete and I had a running version of Minefield.

I'm now in the process of building on Fedora 7 which I installed on a virtual machine on my desktop. Hope it goes smoothly and will post an update when its done.

UPDATE:

The build on Fedora went fine... in fact I would say better than fine since it only took a little over 70 minutes. But what is strange about this is that both builds were done on the same hardware... the first being in Windows XP SP2 with 1GB of RAM and the second in Fedora 7 running inside XP on a virtual machine, with a mere 256MB of RAM -- a quarter of the memory that was available during the first build. Whats even stranger is that this was a debug enabled build where as the one on XP was not. Someone on IRC (andrew) was suggesting that this may be due to my anti virus software so if you haven't compiled Firefox yet you may want to consider shutting down your AV for the duration of the build when you get around to it.

Building Firefox

So I set out late this evening to try and build Firefox. I read a few of the blogs on the subject and decided to use Simon Jung's tutorial. Unfortunately however, I encountered an error that I could not correct. This is my output when I issue the following build command:

make -f client.mk build MOZ_CO_PROJECT=browser

In addition to the error I'm getting, my .mozconfig.mk file also keeps getting overwritten with the following version:

# gmake
# This file is automatically generated for client.mk.
# Do not edit. Edit /c/Documents and Settings/xRayon.AKDESKTOP/.mozconfig instead.
# To create a new .mozconfig file, you can visit,
# http://webtools.mozilla.org/build/config.cgi

# PATH=/local/bin:/c/mozilla-build//wget:/c/mozilla-build//7zip:/c/mozilla-build//blat261/full:/c/mozilla-build//python25:/c/mozilla-build//svn-win32-1.4.2/bin:/c/mozilla-build//upx203w:/c/mozilla-build//xemacs/XEmacs-21.4.19/i586-pc-win32:/c/mozilla-build//info-zip:/c/mozilla-build//nsis-2.22:.:/usr/local/bin:/mingw/bin:/bin:/c/Program Files/Microsoft Visual Studio 8/Common7/IDE:/c/Program Files/Microsoft Visual Studio 8/VC/BIN:/c/Program Files/Microsoft Visual Studio 8/Common7/Tools:/c/Program Files/Microsoft Visual Studio 8/Common7/Tools/bin:/c/Program Files/Microsoft Visual Studio 8/VC/PlatformSDK/bin:/c/Program Files/Microsoft Visual Studio 8/SDK/v2.0/bin:/c/WINDOWS/Microsoft.NET/Framework/v2.0.50727:/c/Program Files/Microsoft Visual Studio 8/VC/VCPackages:/c/WINDOWS/System32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/mozilla-build/moztools/bin

This happens every time I run the build (or clean) command. I have no idea what the error message at the end refers to or why the configuration file is getting overwritten but will be investigating it further tomorrow. The .mozconfig.mk file (/c/Documents and Settings/xRayon.AKDESKTOP/.mozconfig) the overwritten configuration file is refering to also doesnt exist by the way. Updates to follow.

Project selected!

So I have finally settled on a project for my OSD600 course. My choice - the Plugin-Watcher will, I imagine, involve delving deep into the core of the browser code. This will be a C/C++ heavy project and I chose it for a number of reasons; but I would first like to describe its purpose.

The What
Firefox, as you know, is used by millions of people worldwide. Each of them depends on its continuous reliability and stability.The issues faced by complex software such as Firefox in this arena are immense, particularly so in the case of browsers, since besides having to render HTML and execute JavaScript and the like they are also increasingly used as a host platform for various plugins and third party add ons - some of which have been badly written and/or poorly tested.

As the name implies the Plugin-Watcher will track all installed plugins and make certain that non of them are impairing the browser itself. In the event that a plugin misbehaves by either slowing down or making Firefox unresponsive the Plugin-Watcher will notify the user that something has gone wrong with one of the installed plugins. Me and my partner Brandon are hoping that by the final release (at the end of OSD600) the watcher would also be able to identify to the user the actual plugin thats misbehaving and perhaps provide options such as disabling that plugin.

The Why
I chose this project because it meant that I would have to work with the actual guts of the browser. I'm really hoping that through this experience I will gain a greater understanding and a deeper appreciation for Firefox and open source software in general. This is also a C/C++ project which I have to admit I'm more comfortable with than say JavaScript - same goes for my partner Brandon.


The How
We decided to use Visual Studio 2005 as our development platform. An odd choice perhaps considering we are dealing with an open source project, but we are familiar with the IDE and will certainly require its debugging tools. I'm also considering installing Linux on a virtual machine for testing purposes. I already have VMWare workstation installed and I'm downloading the Fedora 7 DVD as these words are being typed.