A couple of days ago (Friday to be exact) Dave wrapped up our work on mouse lock and a couple of tests we have done and put it up for review. Of course this doesn’t mean we’re done. Aside from getting our work reviewed (which Dave has told us will undoubtedly fail), there are still implementations specified on the w3 specs that we haven’t taken care of or are piggybacking off Mozilla’s Full Screen API. There are also a few tests that we’ve left out because they either just hang or don’t do what they need to do, so as anyone can see there’s still a lot left to do. Luckily there are several people who seem to still be interested in working on mouse lock despite the course being over, myself being one of them.
What’s left to do:
- Finish off the rest of the tests. Should mention that some of these tests may be impossible, we’ve been having trouble getting focus switching to work nicely with all full screen, mouse lock, and mochitest.
- Write Litmus tests for the tests that aren’t possible for mochitests (determining if the mouse disappears upon successful mouse lock)
- Start uncoupling from full screen API so we don’t rely on full screen API to work for mouse lock to work.
- Incorporate the changes we get back from the review
For most of my classmates, this marks the end of having to work on mouse lock, so I want to take this time to reflect on what I’ve done and my thoughts on working on mouse lock. Working of Firefox is incredibly difficult. Just finding the correct place to insert code can be a real challenge. I remember when I wanted to build on top of what’s been done and to make the mouse cursor disappear, it took many hours of looking at a call stack and doing minor manipulations just to see if I’m in the right area. Of course it won’t seem that way when you look at the code… it’s easy to look at the code and say, “Yep, it makes sense to put it there.” For me when I was starting, finding the proverbial sweet spot was quite difficult. Especially before I hooked Firefox up to Visual Studio to debug. Even then, it took me a while of looking at the stack call to figure out where to edit. Aside from finding where to put the code, another area that was incredibly confusing was learning when I could get what objects and what interface I had access to. Perhaps I missed a MDN document regarding how we can tell easily, but I’ve always had trouble figuring out whether or not I can convert one object into another or if my function call to get an object returned the actual object I wanted. However, despite the hardships, I always felt compelled to continue working because what I was doing was something no one else has done, no amount of Googling was going to ever yield an answer to my question. In a way, I felt like I was an explorer searching an unexplored world.
After large parts of the implementations were complete, our class was given a more test oriented task. We needed tests to accompany our patch to ensure we didn’t break anything and that future additions didn’t break our implementations. At this point, because I had inadvertently updated the wiki the day before, I was automatically nominated with making sure all the tests were assigned to a classmate to do. A side effect of this was that I was also put in charge with managing the branch where all the tests will be stored and tested prior to our submission for review. At first I thought the task was going to be easy, because prior to this, I’ve been doing a lot of merge work from Dave, Jesse, and Diogo. So I thought this was going to be similar… boy was I wrong. Initially things started off easy as only three or four people were actually doing their tests and they were, for the most part, available on IRC. Managing the pull requests from them were simple and easy. When everyone else in the class began participating a few problems popped up:
- Because IRC was only suggested and not required, when a pull request needed a fix, the main way to contact them was to use github’s pull request comment system. It’s fine for what it is, but unlike messengers, people usually don’t idle on github for very long.
- Although information being up on the wiki or on a FAQ, not everyone (in fact it was the majority) reads it, so they make their own templates despite one given to them, and they make pull requests to the wrong repository.
- Some people don’t update their repository prior to their pull request despite being told to, which meant that they coded their work based on Firefox code that was many revisions behind.
- A side effect from the above is that they had merge conflicts with other people because everyone had to modify the makefile.in in order for the build tool to incorporate the test.
- A lot of people didn’t actually RUN their code before submitting the pull request.
Regrading which of the 5 problems I had the biggest issue with, number 5 beats out all the others by a wide margin. I had thought that it would be standard practice to make sure what you do doesn’t break everybody’s work. It was often not the case. Unfortunately, due to time constraints I usually accepted a pull request if github said it was okay to merge in without looking at the code too closely. In hindsight I should’ve given all the code a quick glance to see if it works, but I had my own test I had to do at the time. Imagine my surprise when upon finishing my test, I update my local repository and find that I can no longer build. Thankfully because we were working only on tests, it was only the makefile that needed to be fixed.
As with most things done for the first time, some tests were not written properly or simply did not test what they were supposed to do. A few of the tests were written in vacuum where the test writer had not come on IRC to discuss the details of their test, so they did not do what was expected of them. This lead to a peer review of the tests which also included the need for a harness for tests that needed full screen. By Friday morning, 4:30am to be exact, about half the tests were converted to the proper harness format and tested what they should be testing. The last two weeks were incredibly exhausting. For the two weeks, I slept around 3-4am in the morning and depending on the day I had to wake up between 7-9am to make it to class. I assume this is how it feels to be in crunch time at a large software company just prior to release.
I’ve learned so much working on mouse lock so far, I’m sure I’ll continue to learn from it as mouse lock implementation gets for fleshed out. The experience I got from working on mouse lock is so uniquely different from anything I’ve experienced before, if I were an RPG character, I can safely say I leveled up.
——
This week is exam week, and there are still some tests that need to be done. Hopefully, I’ll find the time to take a more in-depth look at one or two tests that don’t have a primary reviewer sometime this week. Otherwise, I think I’ll be spending my free time between semesters mapping out various parts of Firefox, particularly parts that might influence mouse lock implementation.