Monthly Archives: February 2012

OSD700 – Release 0.6

Truthfully a smaller release than what I wanted, at least in quantity of work accomplished. This release relied more on research along with trial and error. Although even then, still lacking in my opinion.

What I think is most important from me in this release is the fact that I am transitioning to more difficult tasks. Things that require a decent bit more thought behind them.

My work has been primarily involved in two tickets.

Bug 720768 – Add an equivalent to DispatchToSelf in nsContentUtils
Bug 516811 – “load” events for poster image loads bubble out

With Bug 720768 it seems pretty simple on the surface because of some of the work I have done in the past. All that needed to be done was remove duplicate code that appears in multiple places and add a helper method to nsContentUtils that will cover the removed codes functionality. The problem here comes with dealing with the version of the code in SmsManager.cpp. When initializing this event there is a static cast being done which is completely different than how it is done in any other place in the code. At this point I’m trying to speak with some of the people experienced with that area of the code because from what I can tell/what I know, I don’t think it can be done completely with this one method.

With Bug 516811 there is a problem with the load event for a videos poster image. This one is going to involve adding a new method that will catch the load event itself so I can suppress it and fire out a different one instead called mozposterloaded event instead. I’ve looked over some of the code plenty and it’s going to involve some work with the EventStateManager. Time to open up some of the mouselock code and talk to Steven, Diogo and Raymond some to get an idea of where I should be looking!

Again, rather short on this release. I wish I was able to do a lot more work but other things (cough PRJ666) take up too much of my time :/

See you in two weeks!


OSD700 Release – 0.5

Another two weeks gone by and times are getting even busier! I’ll admit from the get go, I definitely didn’t get nearly enough done as I wanted. However, I still got work done across four tickets.

Bug 698381 – Make Node.cloneNode’s first argument (aDeep) optional, default to true
Bug 698381 Branch

Bug 718274 – Add ::DispatchTrustedEvent and ::DispatchEvent to nsContentUtils
Getting Access to and Using the Mozilla Try Server

Bug 720768 – Add an equivalent of DispatchToSelf in nsContentUtils

Bug 725289 – Remove the moz prefix from Blob.mozSlice
Bug 725289 Branch

If you read my blog with any regularity (I.E You are my mother), you may have noticed I posted a bug that I did work on in my last release as well. I have not done additional coding work on this bug, however it did push me to get a level one Mozilla hg account which allows me to push builds to their try server. This is incredibly beneficial because it allows me to run their over 600000+ tests on multiple systems all at once. Try doing that on your own machines!

I also took two new bugs. With 720768, I was tasked with adding another utility method to nsContentUtils. The point of nsContentUtils is to reduce code and have one instance of this code. It not only cuts down on confusion but it’s much easier to maintain. The only issue that I have come across with this ticket is the one subtle difference in one of the areas where this would be used. When they are initializing the event they are doing a static cast on the result. I’m not quite sure how to work around this to be honest and it’s that one issue that has left me at a stand still with that ticket.

With 725289, it was pretty simple. Change the nsIDOMFile.idl, change all the places where this method was declared, change the tests using this method. With all the work I’ve done in previous ones this took no time at all.

After working on 725289 I was actually able to see that just putting numeric values in the method calls for the optional argument counter was actually an A-OKAY thing to do, at least in C++ land. That allowed me to have a patch finished for 698381 tonight quickly. Hoping this will cover most of what they want, other than probably a test.

Where to go from here
I want to find more challenging bugs to work on. I’m glad that I’ve worked on all these various tickets because they have allowed me to touch various bits of the code here and there, gaining a better understanding of it all little by little. I’d love to find something big like Jon Buckley’s implementation of crossOrigin attribute for the video element. While that one may be a little bit too much, I’d like to aim for something close.

Till next time folks! Get Hacking!

Getting Access to and Using the Mozilla Try Server

There are obviously some guidelines available on the Mozilla Developer Network to help with all of this already, but I figure I’ll help with a nice abridged version that will cut through the fat to get at the meat and bones.

First things first. You will need a Mozilla hg account

  1. File a bug in the Repository Account Requests component. Okay okay, TECHNICALLY you are supposed to read the Commit Access Policy. It talks about the reasoning behind why they chose this kind of system and what each level entails. And since I doubt anyone reading this post needs above level 1 access (probably can’t skip levels too I guess) there isn’t much of a need.
  2. Fill out the ticket. This includes an appropriate bug title/name (E.G. Commit Access Level 1 for FirstName LastName). You will also need to include your public ssh key attached as a plain text file. Since I’m guessing you, the reader, use git then good! You can just use that very same one. Copy it to somewhere more accessible than you ~/.ssh directory and attach it to the bug. Finally, add the email you want to use as your account name.
  3. Next you need to send in a completed Committer’s Agreement. You have a couple of options here. You can print out the PDF and physically mail it to them (How old fashioned….), send them an email using the plain text versions in that link (Must be a S/MIME-signed email. I have no clue what that means so don’t ask), OR, like I chose, print the PDF fill it out and scan it onto a machine and then attach that to them in an email.
  4. If you followed the steps properly you will be notified when you have gained an account along with appropriate information. If something went wrong, you will get notified as well.

Now on to pushing patches!
Yeah, now your forced to use hg/Mercurial. I know it sucks. Thankfully you can avoid it in all other aspects and this part isn’t too painful.

  1. Obviously you will need this installed in some fashion. Mercurial can be downloaded here.
  2. You will need to clone mozilla-central to somewhere on your system. Fairly simple:
    hg clone
    Switch to the mozilla-central directory when you are done.
  3. Like Git you can create custom aliases to make frequently used commands less painful. Create a file called .hgrc in your root (~/) and open it. I borrowed these from Jon Buckley:

    username = FirstName LastName

    mq =

    git = 1
    showfunc = 1
    unified = 8

    diff=-U 8 -p
    qdiff=-U 8

    try = ssh://

    nuke = strip 'roots(outgoing())'

  4. Next you will want to create a file called try in your repo. In there you will want to add the options that tell the try server what systems/types of builds you want to use. You can figure that out here. However most of the time using the defaults is perfect. Copy the text from the textbox on the page and place it in the try file you made. hg add that file and then hg commit -m “Some message, best to use the options you put in the file”.
  5. You will need to add the mozilla try server to a hosts config at your .ssh directory. Chances are you might not have a config file in that directory already to do touch ~/.ssh/config. Open it now and add this to it:

    User emailYouRegisteredForYourAccount
  6. Now you will want to ensure your mozilla-central repo is up to date and need to do a pull. hg pull will do.
  7. Now you get to import your patch. Once again this is pretty simple: hg import ~/Path/To/Your/Patch
  8. Use one of your handy dandy little aliases and simply use the following command: hg push -f try
  9. If all goes well you shouldn’t have any problems as I’m fairly certain I included all the steps I missed that gave me problems. After that use another one of our handy aliases that helps return repo back to normal: hg nuke . You should receive an email shortly containing a link to your builds information.

Yay, you can push your patches now to the try server to have all the 600000+ tests run against it on multiple platforms at once! No more doing it yourself (although if you did this before, well, you’re probably insane).

Happy hacking!

More CloneNode Work

At this point I’m a little stumped with the bug only because what one person suggested to be to do doesn’t make sense based on my knowledge. It was suggested to me that I consider writing an overloaded version of the cloneNode method but I’m willing to bet my errors in regards to places in code looking for a 3 argument version rather than 2 are because I’ve missed something somewhere. It just doesn’t seem like the correct fix.

In the mean time I’ve started the process for getting level one hg account so I can start running some of my patches on the Mozilla Try server. Hopefully I will get this soon so I can finish off Bug 718274 for good!

As well I’ve gone an grabbed another bug. This one involves adding more functionality to nsContentUtils. A lot of the upcoming features with Firefox are implementing a method called DispatchToSelf, all of which have common functionality in them. Basically I’m going to change things up to help save some code here. Should be fun!

Anyway, that’s all for an update this Sunday. Happy Hackin!