Mozilla development and open source blog

Thank you Fedora.

2008-07-17T07:41:00.000-07:00

So about 3 weeks ago, I started having some serious issues with my system. The system would start acting very strange and then eventually spontaneously reboot itself. By acting strange I mean that the system would work fine, until it started working in continuous short bursts following short periods of complete inactivity.

I have Corsair RAM in my machine, the kind that has the activity LEDs on it, and these LEDs were also acting strange, again showing the unusual burst of activity pattern followed by pauses of inactivity. I immediately thought this might be memory related so I left Memtest 86+ (available free through the link) running for the night only to discover that my memory was likely just fine.

So after a long week of arduous troubleshooting I narrowed it down to the SATA drive I was running the OS off of. Looking through the drive's S.M.A.R.T info revealed that the drive was failing (SpeedFan gives you a nice breakdown of your drive info). I also have 2 other IDE drives in my machine which up until now I have been primarily using for storage. I backed up one of them on an external drive and installed XP on it hoping my defective drive would last long enough for me to back up my most important data.

The good news was that once XP was installed all of the problems immediately went away (confirming the role of the SATA drive in the problems I have been having), and I also managed to grab some of the most important data off the defective drive for backup. I figured I could breath easy for now and get the rest of the data off later on. Well in retrospect that was a mistake, as the next morning when I woke up, the drive was gone.

Now you would think this would be the end of the story, except that a week later, upon waking up, I discovered that my system was hung and required a reboot. After restarting the system I found out that my dead drive had come back to life. Needless to say I was exhilarated, in the sort of way that I rarely am upon waking up. However, my excitement at the thought of having my data back did not last long, as I had quickly discovered that while the drive was available, it was not accessible and neither was the data in it.

Not intent on giving up, I decided to try my best to get that data off even if it took me all day (the data I'm referring to was mostly composed of pictures - 3.5GB worth of family pictures that while not crucial, certainly had a lot of sentimental value - especially since many of them were not backed up anywhere else). So on I went running CHKDSK and Western Digital diagnostic utilities, wasting many hours with absolutely no luck. I then decided to give Linux a shot. So I downloaded Fedora 9 Live, burned the ISO and booted into the OS. Thanks to some instructions I found on a blog post by Rodney Fletcher, I was able to determine the commands to mount an NTFS partition in Linux and decided to see what would happen. Unfortunately, while I was able to mount my external drive without a hitch, trying to mount the defective drive ended up repeatedly hanging the live OS. About to admit defeat, I booted back into XP only to discover that whatever Fedora did while trying to mount the partition on the defective drive, allowed me access to the partition's content. Overjoyed, I started frantically grabbing the data and copying it to my external drive. Everything seemed to be working well except that a minute or so into the copying process, my computer resumed the strange burst behavior it was exhibiting with the old XP, which also stopped the copying in its tracks.

After rebooting and trying again a number of times without any real success, I noticed that just as the strange behavior started, Windows was outputting an unusual message, notifying me that a delayed write action had failed on the defective drive. I thought about this for a while and I could not figure out why would anything need to be written to the drive during the copying process. I never actually figured that out but I did come up with an idea and a plan to solve the problem. I realized that reading from the drive seemed to be working just fine, until something attempted to write to it, at which point the strange behavior commenced. I realized that if I could make the drive read-only, perhaps the problem can be avoided and I can get my data off the drive. The only problem is that Windows does not support making a partition read-only. So off I went looking for freeware that might do the job.

Unfortunately I could not find such software (an idea for an open source project perhaps?), but I was able to locate a shareware by the name of HDGuard which among other things allows you to designate a partition read-only. I jumped through some hoops and managed to download their 30 day trial version. After a simple install, a bit of configuration and a couple of reboots I was finally able to get my files off that dreaded drive.

So to conclude:

Thank you Fedora, thank you Rodney Fletcher, thank you HDGuard, thank you TeraCopy (a great free program that replaces the dreaded Windows copy utility) and thank you Western Digital for having relatively long warranties and a relatively hassle free RMA service (and sorry for the unusually long rant!).

New PluginWatcher extension release (v1.1)

2008-07-05T23:58:00.000-07:00

An updated version of the PluginWatcher extension (version 1.1) is now available for download from the Mozilla add-ons website. It is currently in the sandbox, awaiting approval from an editor.

The new version primarily adds the ability to customize PluginWatcher's UI while also introducing a number of changes to the core of the extension. In the UI department it now also offers a second panel, displaying the plugin activity expressed as a percentage of utilization. The biggest change, however, is in the way the extension calculates the plugin load on the system - that algorithm has now been refined and it should prove to be significantly more accurate. This release also addresses some of the packaging issues that were observed with the previous xpi; mainly it provides a much cleaner and smaller xpi file, containing only the files that are required by the extension.

I also plan on releasing version 1.2 of the extension soon, as I already have a number of ideas for possible improvements. If you care to try the new version, it can be downloaded here (since it is still in the sandbox, you will need a Mozilla add-ons account to install it). Feedback is as always welcome.

Spring cleaning

2008-05-06T14:10:00.000-07:00

If you ever had to clean up your drives of all the junk that accumulates there over the years, you know this can be a time consuming, less-than-fun task to go through. But if you are using Windows OS, there is a very simple and effective (and open source) tool to help make this into less of a chore. Its called WinDirStat and it provides you with a meaningful visual representation of whats taking up space on your machine.

This is what my drive looks like after getting rid of the biggest space offenders:

The big gray block on the left (highlighted in white) is the post cleaning free space I have gained (approx. 65GB freed).

Get all the info here!

UPDATE:

I am not a MAC user but was made aware of a similar program for OSX called Disk Inventory X. You can find out about it here!

Hat tip: Lukas Blakk.

And of course we can't leave the Linux community behind... so if you are using a Linux distribution you can use a similar application called KDirStat, find out about it here!

Hat tip: James Boston.

Linux minefield and plugins

2008-05-06T13:40:00.000-07:00

If you are as unfortunate as me and need to work with plugins (like Flash) running on a fresh build in Linux, this post could save you hours of frustrations. The problem is that the automatic plugin installer that comes with Minefield doesn't realize that it was built as opposed to being installed, and so when it fetches the required plugin it ends up installing it in the default location -- "/usr/lib/mozilla/plugins". Unfortunately this is not the location where Minefield looks for the plugin .so files. In order to actually install a plugin on Minefield you will need to first locate and then copy the .so file to Minefield's plugin directory -- "/mozilla/?ObjDir?/dist/bin/plugins". Then restart Minefield and you should be in business!

The story of one Hotmail and a Blackberry

2008-04-24T21:30:00.000-07:00

If you are the owner of a Hotmail email account and a Blackberry (I own neither, but my uncle had the former for years and acquired the latter a couple of weeks ago to get his emails faster) you may have already tried forwarding your mail from one to the other, perhaps because the person at the store told you it works with *all* web mail services (as was the case with my uncle), merely to discover the sad truth: it doesn't!

Open source to the rescue. After a bit of looking around I found this great little POP3 server proxy called FreePOPs. What this great little program does, is it allows you to retrieve your free web mail messages with any application or device that supports the POP protocol (including a Blackberry). The best part is that it works with most popular free web mail providers out of the box (and some less popular ones too) and it is extensible, so in theory support could be easily added for almost any service. It's also very light and very much in the background.

While this is an easy way to get your Hotmail messages on your Blackberry, it can also be used to get them in your Gmail inbox. Gmail's options include retrieving emails from a different account that supports POP3 access. The only downside with Gmail's POP retrieval is that you don't get to control how often it checks - which at times could mean as long as an hour between checks. Still, it sure beats paying for Hotmail Plus just to be able to forward your mail.

Pesky email problems like these are all too common, which is also why I'm posting this up in the hopes that this might be of some use to people out there looking for a similar solution.

You can find a download link for the program as well as more info right here.

PW Core/Extension Docs Up

2008-04-24T18:39:00.000-07:00

So PW Core is finally in the tree and is available in nightly builds as of April 24th, 2008. The extension is also up and running on Mozilla's addons website and can be downloaded here.

I have also created draft support documents for both PW Core and the extension:

PW Core

PW Extension

As always, your feedback is appreciated!

UPDATE:

The article on PW Core has been generalized and moved to MDC. Find it here.

Also, thanks to Cesar, my extension went public on AMO. See link above for download page.

PW v1.0 and Final OSD700 note

2008-04-18T20:48:00.001-07:00

Well this certainly feels a little strange. I am now technically a CPA graduate - but its not really sinking in yet. PW v1.0 is done and I must admit I'm very happy with the end result. It has certainly come a long way since last September. You can find all the info on this new release on my wiki as always.

Now I would like to thank the many people who have been a part of my journey and helped me along (in no particular order):

Dave (humph), Chris (ctyler), Robert (roc), Mark (mfinkle), Mike (shaver), Gijs, Armen (armenzg), Cesar, Andrew, Lukas (lsblakk) and Ted (for his extension making script -- really useful!!).

Thank you all and I hope I'm not forgetting anyone!

PW Extension v0.91 is out

2008-04-16T02:48:00.000-07:00

A new extension is now available. Here are the changes that occurred since the last update (v0.9):

- The extension can now be enabled/disabled directly from the status bar icon.

- A new popup notification appears above the status bar meter if a consistent high run time is detected.

- The extension now listens for the new "experimental-notify-plugin-call" topic name

Please note: the latest extension only works with the latest PW Core patch (v0.91).

Find the download link and installation instructions on the project wiki.

PATCH going "experimental"

2008-04-16T01:29:00.000-07:00

There has been some discussion surrounding my patch among the more senior developers at Mozilla today and as a result I have been commissioned to change a small part of the code. The part in question is the topic with which a plugin's run time value is broadcast through the observer service.

Formerly known as 'notify-plugin-call', it is now named 'experimental-notify-plugin-call'. This change may seem small or insignificant but it actually makes a lot of sense, especially when you consider that the way the run time is currently determined and communicated is almost certain to change in future releases. This change will also mean a new version of the PW extension as it needs to be adjusted to the new topic, but the new version will also incorporate some improvements to the UI as well.

A number of people have also noted that in the performance test charts I have posted recently, the y-axis does not start at 0. Admittedly this was a bit of an oversight on my part, especially since when you do have the y-axis start at 0 my case for PW becomes much easier to make. I have therefore recreated the chart for the two tests I posted earlier - this time with the y-axis properly labeled:

Test 1

Test 2

What a day...

2008-04-15T18:03:00.000-07:00

So this morning I submitted my pre-final core patch for review and got some very positive feedback. In fact it seems that as far as the core patch goes it will remain mostly the same from now until the 1.0 release. It is also ready to be checked into the tree but will most likely not make it into FF3.

In addition to releasing the latest patch, I had also created a performance test that allows a user to time how long calls made from JavaScript to an exposed Actionscript function take. The idea behind this was to run the test on a fresh build and then run this same test on a build that includes my patch. By comparing the two, it should be possible to determine what sort of overhead my code creates.

Below are the latest 2 tests that I have run:

Here is the result from test run number 1

	PW ON	PW OFF
Test 1	3135	3174
Test 2	3144	3156
Test 3	3139	3130
Test 4	3140	3175
Test 5	3161	3135
Test 6	3144	3153
Test 7	3156	3173
Test 8	3154	3139
Test 9	3146	3165
Test 10	3153	3154
Average	3147.2	3155.4

And some screen shots:

Test run with PW OFF:

Test run with PW ON:

Test 1 data plotted on a bar graph:

Test number one was run on minefield 3.0pre, with PW OFF running first.

And here is the result from test run number 2

	PW ON	PW OFF
Test 1	3176	3142
Test 2	3399	3160
Test 3	3197	3137
Test 4	3142	3159
Test 5	3155	3137
Test 6	3172	3141
Test 7	3152	3167
Test 8	3177	3148
Test 9	3166	3148
Test 10	3165	3162
Average	3190.1	3150.1

And some more screen shots:

Test run with PW OFF:

Test run with PW ON:

Test 2 data plotted on a bar graph:

Test number two was also run on minefield 3.0pre, with PW ON running first.

What these runs suggest is that the overhead that is created by my code is so minute that the difference simply "drowns" in the noise. As Chris Tyler (ctyler) put it, that places it firmly "into [the] 'who cares' territory". I tend to agree!

Demo 2 and PW Extension v0.9 + screenshots

2008-04-01T01:12:00.000-07:00

So in my previous demo (demo #2) I showed Dave what was then the initial concept for the plugin activity meter. Since then I had fixed some bugs and removed a substantial amount of code.

I have decided to remove the plugin recorder feature from the extension as it would not be of much use to most end users. Instead I'm considering making the recorder into its own extension, in case anyone would find that sort of thing useful. The recorder is in fact its own class, and should be easy enough to transplant into an existing extension skeleton; for now however, there are more immediate issues I must tend to, so this will be on the back burner for now.

A lot of the missing code can also be attributed to the old method by which PW made the decision to notify the user of a high runtime. The new method is much more compact - considering it consists only of about 45 lines of code vs. the old method totaling almost 120 lines. The major difference between the two methods is in the usefulness of the information each provides. The old method sampled the runtime values over a given period of time. If a runtime of 'x' or more was reported 'y' or more number of times, the system would notify the user that the plugin might be consuming too many resources. The current method by contrast samples the runtime values within a given period of time, totaling them and then calculating this as a percentage of total time (the sampling time). The new method makes away with most all of the somewhat clunky settings in the previous extension and it also allows for a far more informative graphical representation of the load compared to that of the old method.

So now for some screen shots of the new graphical components:

First what it looks like in its inactive state.

Active, with a plugin running.

Various flash content.

Youtube video playing.

Flash video loading.

Flash based game.

Can't forget the new and compact settings dialogue.

Now that the extension is taking shape for the 1.0 release and the core patch is inching closer to the tree, I'm going to concentrate on getting the performance testing under way. In the meantime feel free to try out the extension for yourself. The details are on the project wiki page: click here.

First demo, new Plugin Recorder features and a new core patch

2008-03-20T23:01:00.000-07:00

First Demo:

So I had my first demo yesterday, which turned out pretty well I think. Looking back, it does feel like I have come a long way, and doing the demo helped cement that thought; which strangely motivated me to start working on some of PW's more exotic frontiers - namely lack of OSX support and the somewhat shifty Unix compatibility. To that end I started debugging late last night (or early this morning) and managed to find where all that plugin fun happens. Also I owe Mike Shaver (shaver on IRC) a big thank you for helping me make sense of that hairy code. Now I feel closer than ever to being able to implement PW on all platforms uniformly.

Plugin Recorder v0.2:

There have also been some developments in the new Plugin Recorder feature of PW - I have implemented a new option that allows the user to control how the data gets written to the file. Admittedly however, this feature would not be of great use to the large majority of people who might otherwise have interest in using PW's notifications feature. Because of this I will be shifting most of my attention to creating some type of a graphical notification feature using some sort of an existing graphical library. If you happen to know of a good one that would fit this task, don't hesitate to tell me by leaving a comment!

For those of you interested in seeing, I have created a screen capture video of a flash plugin and its run time being charted in real time using LiveGraph. I am working on compositing the two videos together and will post a link here to the uploaded video when its done.

New Core Patch:

In my second review from Robert (roc on IRC), I was instructed to switch some of my code from a MACRO into a helper function. This new PW v0.81 core patch addresses this issue by introducing a new file to the mix - dubbed nsNotifyPluginCall.cpp. This was a slightly more challenging implementation compared with the MACRO solution I came up with initially, but it was a great learning experience - teaching me how to include new files in a patch and enriching my knowledge of the build system in general. I have not yet received any feedback for this patch, but I'm fairly confident Robert would be satisfied with the changes, as they do seem to address most all of the points raised in both his reviews (Update: new review has been posted by Robert, currently working on updating my code). The only point this patch fails to address is the performance testing which still needs to get done. After talking to Dave (humph) and Chris (ctyler) I think I have a more concrete plan as to how to go about this testing. The first thing I would need is to locate (or more likely create) a page that contains a loop with JS calls into a flash object. Once I have that I would need to create a script that opens Firefox, launches the plugin page and closes the browser when the loop is done. Calling this script with the "time" command, both when PW is present and when it is not, should give me an indication if my code affects performance in any significant way.

New patch and new extension feature to assist with benchmarking

2008-03-17T05:10:00.000-07:00

So for this 0.8 release I had done two things.

The first thing I did was some major surgery on the C++ code me and Brandon wrote at the end of last semester in OSD600. That code has not changed much since then and although these new changes are still largely cosmetic by nature, I do hope they bring me closer to the final product and ultimately to having the code integrated into FF.

The second thing I had done was add a new feature to the PW extension. This new feature allows you to record a plugin's run time to a file. If I'm correct, this should make benchmark testing of various plugins much easier. I still have to add some functionality for this feature as it is pretty basic right now but I was still able to hook it up with liveGraph (open source real time charting software) to produce a real time graphical representation of the plugin's run time. I'm planning on posting a video depicting this, as soon as I find a good screen video capture software. For now you will have to enjoy this lovely screen shot:

In case you are wondering, this depicts an interactive flash object running for approximately 8 minutes.

If you would like to try the new extension you must also use the new 0.8 patch, otherwise this will not work. You can download the necessary files and read the installation instructions on my wiki page.

As always, your feedback is appreciated, and if you have a plugin that you would like tested leave a comment with the plugin's name and a URL to a page containing it.

0.7 is Out

2008-03-04T19:32:00.001-08:00

So for the 0.7 release I decided to concentrate on making the newly created extension useful and usable. I fixed some bugs and added some options to allow the user to control what should constitute a high run time they would like to be notified of. Also in the option dialogue you can now view the actual run time in real time which would be helpful to anyone installing the extension on a non debug build.

Here is a summary for all the new changes and additions:

Fixed notification bar bug where the user notifications would collect one on top of the other. The notification will now only appear if no other PW notifications are present.
Added option to turn PW on and off in the context and Tools menu.
Added a preference panel to the extension where a user can control various settings of PW.
- Users may turn PW on and off.
- Users may change the monitoring settings of PW to notify them when a certain run time has occurred, a certain number of times, within a certain period of time.
- Users may view the current run time directly in the preference panel.

For instructions on how to install the new extension please refer to the project wiki page.

PW extension release

2008-02-18T01:58:00.000-08:00

Back in mid December, when me and Brandon were closing in on our final submission of Plugin Watcher (0.31), we had to go against Mark Finkle's advice and hack our JS code directly into 'browser.js'. Mark had told us how inelegant this solution was, and this is the reason that my 0.6 release is the Plugin Watcher Extension. This extension listens to the runtime notifications of your plugins and notifies you if they exceed a certain limit a certain number of times per certain amount of time. At the moment the extension does not add any new functionality, but I'm working on including various configuration options in the future. To try the extension out click here to get to the project wiki.

Releasing PW 0.4

2008-01-17T06:47:00.000-08:00

Not too much thats exciting in this release but I did just file a bug with the PW 0.31 patch. I'm hoping this will start the ball rolling towards v1.0 and provide me with lots of new ideas and suggestions. Click here if you would like to see the bug and please don't hesitate to leave a comment or two of your own if you have any remarks, suggestions or any criticism at all - all of your feedback is valuable and highly appreciated!

Rebuilding firefox and starting OSD700

2008-01-14T04:56:00.000-08:00

So this has been a hectic first week of school but things finally seem to be calming down a little. I thought I would take this time to (a) let you know what I have been up to and (b) describe what I hope to achieve in the next 4 months in OSD700.

So regarding part a - I decided to rebuild minefield last night on my home desktop. I did this partially because I still have not been able to checkout an XPS laptop from ORI but perhaps primarily because I had recently upgraded my computer from 1GB to 3GB of ram and was curious to see how that might affect the build time. As some of you may recall, when I first tried building the source tree on this machine it took no less than 10 hours, so I was rather curious to see how much shorter the process will be with the new hardware. Unfortunately however, I got an error during compilation and therefore I can't report on any improvements for now. I will be trying again shortly though and will post here if you are curious.

And as far as part b goes - I have given it some thought and came up with the following list of things I would like to achieve for my 1.0 release:

File a bug with my 0.3 patch and get some feedback for the code.
Work on the code in accordance with the feedback I receive.
Get the code to work on macs.
Get the JS portion out of the browser and into a proper extension.
Improve the heuristics of the front end extension.

I have also thought of some other things that I could do - outlined below - but whether these goals can actually fit into the schedule remains to be seen (I assume this would largely be dictated by what sort of feedback I receive for the code on Bugzilla):

Provide more information about the plugin that is causing the issue.
Provide a way to disable the plugin.
Add code to the front end JS that will collect and display statistical information about plugin runtime.
Do plugin benchmarking and publish the results.

As always your comments are welcome!

0.31 is now out!

2007-12-16T04:30:00.000-08:00

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

2007-12-15T14:52:00.000-08:00

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)

2007-12-14T04:08:00.001-08:00

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

2007-09-30T10:18:00.000-07:00

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)

2007-09-22T15:11:00.002-07:00

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

2007-09-20T01:03:00.000-07:00

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!

2007-09-18T23:22:00.000-07:00

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.