It’s funny, if you were ask me 5 years ago, if I would associate legacy with something good or something bad, I would’ve definitely said good. Legacy… it SOUNDS good, prior to entering the world of programming much of my exposure to the word legacy were in the form of “so-and-so hero left a legacy” again, a good thing. So I was rudely introduced to the fact that often times in the programming world legacy can be equated to outdated and not-maintained.
For all the great teaching and experience I get while studying at Seneca, most of the time, code is created from scratch. Due to this, our projects are almost always small scale assignments, even group projects are relatively small (until professional options anyway). The amount of exposure students get with regards to large code bases, or dealing with existing-but-buggy code is almost nil. Even for projects where the professor suggests sources for code we can use, much of the code is either in copy-and-paste condition or better code can be obtained through a web search where we can THEN copy and paste. Rarely do we have a chance to touch code where there’s not necessarily a “better” alternative and where we just have to buckle down and decode the program in front of us. So reworking some of these mouse lock tests became just that, of course much of it was my fault to begin with…
I’ve done group work in programming classes and I’m tutoring at Seneca’s Learning Centre, so I’ve seen my fair share of coding differences. However, when I started to look over the tests again, wow. There’s a lot to be learned from reading other people’s code, and learn I did. Unfortunately the flip side was that there were a few tests that either tried to do the impossible or tried to do something but was unsuccessful. The problem was the amount of time it took to decode some of the tests that were written in order to determine if the tests needed to be changed, updated, or even removed. Luckily Steven was there to help me and took a little over half of the tests that were peer reviewed to look over.
In the end, I dealt with file_MouseEvents, file_defaultUnlock, test_mousePos, file_movementXY, file_targetOutOfFocus, test_MozPointerLock, file_limitlessScroll, and file_userPref.
There’s no point talking about what changes happened to each individual file since most of the files were actually fairly simple fixes, they just needed minor updates to make sure that the tests worked with the new patch. However, because some of the original authors of the code are no longer working on this project, it’s important for us to understand what it does so when review comes (and we’ve been told to expect the worst), we can get it fixed ASAP.
Looking back the past week at what I said, I underestimated both the amount of free time I would have, as well as how long it would take to fix these tests. The one test that gave me the most trouble was honestly my own, haha. file_MouseEvents.
The main issue was that it was hanging for some, but not for others. As well, some people were having random success and failures. It took me three days and two full rewrites to figure out all the things I did wrong.
During some of the edits I had made, I left some old pieces of code which in turn, caused the test to sometimes stall there until mochitests finally closed it for being open too long. That was problem one taken care off. As for the random success and failures, it took a while for to figure out, but in the end it wasn’t anything I could really do about it. When the test is run, the mouse cursor MUST be in the browser, otherwise, it won’t be able to do the proper synthesis, at least not on Windows. When I launch the test with the cursor hovering anywhere over the browser, the test will work as expected. Take it away and run it? A bunch of failed tests. That’s not really something I can control and fix, when running mochitests, ideally you’re not doing anything that can affect the browser doing its thing anyway.
Finally I noticed a processleak. It was because of this that I had to do the two full rewrites, but every time I got the same thing.
As you see above, that’s a lot of leaking. I always thought it was my code, that something I coded caused this. After a bit of sleuthing, I found that by calling synthesizeMouse and passing in an event of type “mousedown” and with a button of “1” (middle mouse button), mochitest would leak like this. I found another test_bug549170.html, I ran it, and got the similar results. It leaked like mine. This leak seems to only affect Windows machines because Steven, using linux, did not have the same leak issues. And really, I never heard anyone who was peer reviewing this test mentioning the leak (many of them used a linux box to do the builds and testing).
In any case, the majority of the tests ARE done. Steven mentioned two tests that need to be taken care of. The first is one that will be merged with movementXY, and it deals with testing to make sure that the mouse can move more than 1 screen’s length and height once in mouse lock (it’s easy enough to test it out in real life though, just look at the demo pages haha). The next is do something similar to what I’ve done in file_MouseEvents. In file_MouseEvents, I have one outer div that holds a child div. Once mouse lock is set on the outer div, the child div should not get many of the mouse events. The case that is being sought is to have multiple children inside the outer/parent div. It should be fairly straightforward to rig up. =)
I really need to get into the habit of blogging more often, or else I get these REALLY long pages of text.