Open Source Hacking
Monthly Archives: December 2011
These last 2 weeks have been a real doozy. Massive push for every student I know to get their work done on time, or at least done in some cases. In the end it all must get done and in my case, I had to make sure I finished my work for the bug Rename nsPLDOMEvent to nsAsyncDOMEvent.
The bug itself is very simple and really only required some simple search and replace in the files that mxr reported as containing references to it. Simple stuff really.
The patching processing is a whole other story however. Mozilla uses mercurial for their revisioning system over one like git, so for the rest of us sane people this creates issues when trying to get changes approved because we have to use some magic to to convert our patches to be something that’s compatible with hg (Okay it’s not REALLY magic, more like a handy alias found here).
hgp = show --format=\"From: %an %n%s%n%b\" -U8
This handy little alias allows our patches to have an automatic format to them that’s acceptable for the hg patch system. After that the path has a fork in the road depending on how your development process has gone. If you made multiple commits at all (highly likely if you are working on anything that requires a lot of work, or in my case are forgetful), you will need to rebase your code first and use the fix-up command because this will squash each commit into one, making it all one big “patch”.
In my case I needed to submit this patch a few times because of different style’s than Mozilla is expecting. Unfortunately no one is perfect and it didn’t pass review the first two go tries because of indenting issues. The second one was because I missed one single indent problem that was actually present in the code originally and I just didn’t catch it. Like humph has said many times in open source you inherit the code of others, including their errors!
However I wasn’t done yet there. After the second patch they also asked me to go and change another subclass of nsPLDOMEvent; nsLoadBlockingPLDOMEvent. It wasn’t included in the original ticket but needed to be changed for the same reasons so might as well get that one done as well and kill two birds with one stone. The problems I had here was how I should be constructing my patch now. Should it be everything consolidated into one? Two patches, but both based off of the original mozilla-central code? Or, as I went with in the end, two patches where the latter “piggy-backs” off the changes of the first, meaning the second patch would be based off the I made in my repo based for the first.
The reason why it’s better to keep it separated into two patches is because well, it’s two different changes! Consolidating them into one can lead to potential issues and is simply harder to review so it made sense to do it like this.
At this point the ticket is just about done. My first patch is set to checkin? (basically awaiting confirmation) and my second patch has been set to review+ meaning it passed it’s review and is waiting to be checked in. This has been quite the exciting semester and I have enjoyed it a lot. I definitely feel that I have been able to grow a lot as a developer by being exposed to real world work and the kinds of expectations they have. Had a blast, however it’s not over!
See you in OSD700!
Our class is on the final stretch to getting our first patch ready for review and have a real functioning Mouse Lock API available for use with Firefox. One thing @humphd pushed for was for each one of us to have some piece of code in this patch that we could call stake our name to. During our class Tuesday he made sure everyone of us was assigned a feature and set a tentative deadline for this Friday so we had enough time to get a patch ready for early next week. This was a great thing to do because it ensured we all got something in and pushed those that may not have been doing much work with it or just haven’t been involved much.
One of the features left to implement that interested me was implementing a user preference that would allow the user to have a saved preference about whether or not they wanted mouselock to ever be enabled. My original research into this brought me to this directory in mozilla-central. It definitely provided some insight and allowed me to know how I could access preferences and what their current values are. The only problem was I had no idea where I should have been actually defining the preference itself and any default value it had.
After joining up with @northWind87 today we were pointed in the direction of a wiki article Humph had written about preferences in mozilla. From there we found firefox.js and noticed a lot of lines that looked like this:
Clearly we were on to something. We initially tried adding our preference in to this file and rebuilt firefox around that change. It worked instantly but humph then pointed out to us that @TedMielczarek said we should actually be putting them in a file called all.js, which was actually only one directory structure further down that what I originally found. Not too shabby really, pretty close on the first try!
After that all that needed to be done was adding in a couple of lines of code the the method nsDOMMouseLockable::ShouldLock that we already had and bam, presto chango it worked (at least as far as we could tell). The only thing left to do now is figure out why the results of my testing aren’t showing up.
Till next time!