For reader that is not in my open source class and is wondering what 0.3 Release means, you can ignore them. It is used so that my professor can track my progress and grade me.

For this blog, I will be discussing my troubles with Bug 601535, which I mentioned a little bit in one of my earlier blog.

Background on the Bug

The bug involves changing all instance of MulOverflow and AddOverflow in the content/media folders. In place, I am supposed to use the CheckedInt utility class. This class checks whether the number is valid or not, that is to say, it is this super awesome cyborg that takes in number and tells me if the number is too big or not.

I was a little big lucky off with working on this bug because it was partially worked on by someone else. There is a both pros and cons with regard to having a bug partially worked on. The pro is that I get a decent amount of examples to look through and someone already reviewed the older patch and I get the feedback right away. The cons are I need to understand the bug first, what files it affects and what the earlier person did.

Working on the Bug

This bug was worked on by someone two years ago, and two years in computer code is ten lifetime and the current code is in the tenth generation. This translates to numerous differences in code. As such, my job involved (after I understood the bug properly):

• Get the old patch and put it in my code.
• Put in the suggestions put up by the reviewer.

This may sound simple, but it is not.

Adding the Patch

After I was satisfied with the bug, I began preparing a diff to be uploaded and this took me two days. TWO DAYS TO GET A DIFF!!!! Somehow github was giving me a lot of trouble when trying to rebase. I am going to sit with Jon Buckley, who is pretty good at github and shall see what went wrong.

In short, the code is landed and the diff issue I had to re-do from a different branch. I will soon post a blog once I figured out what went wrong and maybe help someone (me) in need.

So approximately two week ago, the people working on the Pointer Lock API [Dave, Diogo, Raymond and Me] decided to update the bug with a patch. The path to this patch had been a huge challenge to the team.

In short did we manage to finish of this API, the answer is “NO!”. However, are we close to finishing it? I feel we are close. However, it was not an easy task. Over the past few weeks, we were being slaughtered by the code from all directions. It seems like after we fix one problem, five more emerges from different locations. The more we tried to tackle an issue the more overwhelmed we felt. It is like a never ending uphill battle.

In this blog, I will talk about what we managed to accomplish and what else is left.

In my previous blog, I talked about how we managed to crash the test suite when trying to run it on a Mac. Well, it seem that the Mac environment seem to pick up more problems that would otherwise be impossible on a Windows or Linux machine. For example, in one of the test, it executes some code that does deep down into the Mac machine layer code. If you are interested in looking at this bug and think you can contribute to the solution, take a look at the bug problem filed here.

Most of the test cases crashes on areas of code we have never seen. We had issues due to different platforms, issues related with memory leaks when we try to synthesize some mouse events, occasional failures causes by unreliable mouse position values. All these problems were driving the team insane. IT IS FRUSTRATING!!! For example, when Dave tries to run the test suite on a Mac, he get five additional test case than me (on Linux) or Raymond (on Windows). So what did I do then? I shut my machine down, called some friends out to the bar and ordered myself something strong. I need that!

Fast forward a few days, Dave decided to add a patch to the Mochitest environment to try to fix the problem of different number of test. He added an optional parameter when a user is coding the test using the SimpleTest.waitForExplicitFinish function. This parameter tells the test the expected number of test to be run and matches that with the result number of test to see if they all run. If not, it shows a fails assertion. I tried to find this bug so you can read about it on Bugzilla, but was unlucky.

So What is Next?

Well 3-5 days after we added a patch, guess what? They updated the API specification as well. With the new update, they are removing the use of callbacks and are using events. What does part of our code is affected with the change? Well, everything. Now all of our test needs to be re-written, as well as the API code itself.

I guess we start from square one again, sort of.

During the past few weeks, most of the possible test we could think of were working, I think. However, the test had opened up a huge can of “bugs”.

[Updated: Considering the trouble we had on these test, I am calling this as my 0.2 milestone for my open source class]

The Crash

Overall, the crash was caused when a HTML element tag have CSS styling for the “display” attribute. In some of our test cases, we had CSS styles that looked like this:

<div id=”content” style=”display: none”>

The problem with having the “display” attribute set to none is that when trying to lock the mouse, the underlying code tries to get the element “rectangle”. This causes a problem when the “display” attribute is set to “none”, as there is no “rectangle” to be obtained. Thus the crash occurs. If the display is left in it’s default value, that is, the “display” attribute is set to “block” then the rectangle exists and the test does not break.

You may ask why I didn’t go through this crash issue before? Well, the crash seem to occur on isolated incidents on both Windows Build and Linux Build (where Raymond and I have our build on, respectively). For example, I had only two such occurrence that is is impossible for me to recreate to scenario to find a fix and the same happened to Raymond. However, when Dave pull the test from me and ran them, he gets the crash EVERYTIME!!! He was practically unable to run any of the test cases even once.

The Fix

Why is this crash odd? I do not have the answer and hopefully will get one soon from other developers (Dave is asking people involved with the API for feedback).

Until we get further feedback, we are working with a fix where when the element being locked have their “display” CSS attribute set to “none”, then the pointer will not lock. A test is also available to check for this, it is the file_pointerLockCSSDisplay.html file.

For a view on what was changed to incorporate this fix, look at the Diff on my Github account.

Outcome?

A crash like this brings up many questions. Questions like what other problems would the API run into. If someone didn’t put in the styling tag, we would not have known this problem at all. Another question, which is being discussed with people involved with the API specification, should we allow lock to occur when constraints like the “display: none” are present? Would it open up other problems with security? Who can answer these questions?

I wish I knew….

Note: Dave have this blog that explains the problem further

I was working with Raymond Hung to get these test completed. I mentioned in my previous blog about how I was struggling while trying to read other people’s code and make sure they work properly. Well, I am still fighting that war. It will be a war (with numerous battles, of course) that will not end until the day I retire. While reading other people’s code block, it does not just becomes a matter of getting the code to work. I involves a lot more work like making it readable so other people who will review my code will not have to go through what I went and also if they don’t understand, they’ll just throw my code back. It also involved ensuring that all the test follow a consistent format.

In this blog, I will talk about almost all the test we have worked with.

**Note: All the test being linked in this blog is on my GitHub account and as such, the files will be updated from time to time and some of them may even be taken down. It is also good to note that the MouseLock API Draft Specification had changed it’s name to PointerLock and I will be referring to PointerLock throughout this blog and any that may follow.

For those of you who have not been reading and have the time, you may follow up on what have been happening with this test suite through my blog section on the PointerLock API test.

For the impatient, well the test are to ensure that the PointerLock API does not crash for any possible edge cases we could think of. These test must work on Mochitest, Mozilla’s automated regression test framework.

Tests, the gritty details

First in the queue is the file_DOMtree.html. This test is used to check that the mouse can be locked only when the target element is in the current DOM tree. It also checks that if the target is “ripped” out of the current DOM tree while the element is in FullScreen and in locked mode, the mouse loses the lock.

Next up is the file_nestedFullScreen.html, where it test to ensure that when there is a nested HTML tag, lock is not allowed to the child element when the parent is in lock. Why would we do this? Well, ask yourself how many cross-hairs do you want to use when playing a first person shooter? The main reason for this is mainly be allowing lock on child element, it may open up security issues which we definitely don’t want.

Next (on the chopping block) is file_differentDOM.html, wherein we had to check that when there is an iframe element (my Nemesis while using Mochitest), any attempt to gain PointerLock from the content inside the iframe is denied as the requesting element belongs to another DOM which is different from the current active DOM (the parent of the iframe). I think if the child element within the iframe is allowed to lock the pointer, it may allow cross-site scripting which is BAD for the good guys and GOOD for the bad guys.

• pointer.isLocked, which is a validation checker, returns true if mouse is locked, false otherwise.
• the pointer.lock() takes in three argument, namely, a DOM element, a success callback and a failure callback. [this method of operating is currently being debated and the folks are looking at using events instead of callback, which translates to (yup!) "more work"]
• When the element is locked, it fires the appropriate callback immediately. This way depending on the result, the user can execute different actions accordingly. In my honest, I think callbacks are decent to work with, once you get the hang of it.
• Finally, the pointer.unlock() method cancels the pointer lock and returns the pointer (known as a mouse now as it is no longer locked) to it original state and position.

Next up is file_doubleLockCallBack.html. This test is to check that when a pointer is locked, another instance of pointer.lock() still fires the success callback as the the element is still in FullScreen and pointer is still locked (DUH~!).

Now we have file_unlockOnUnload.html, where the pointer must lose it’s locked state when the window unloads. In a nut shell, a window is the first thing that gets loaded in a browser before the document gets loaded (this is properly explained here).

We then have file_extiMouseLockOnLoseFocus.html. As the name suggest, this test check to ensure that the pointer loses its lock state when the current window/document loses focus. A scenario of losing focus is when the user switches between tabs either through alt+tab or mouse clicks, then the window/document loses focus and pointer gets unlocked.

file_pointerLockLost.html is a test that is used to check that when the mouselocklost event fires, the bubble attributes are set to true, and the target attribute is the element that initiated the lock. (For details on what is an event bubbles, refer to this page).

The file_defaultUnlock.html file is used to check only when default keys are pressed with the element lose it’s locked state. For example, when a user press the letter “a”, the element should not lose it’s locked state. However, if they press the “ESC” key (which is set as the default), then the element loses its locked state.

In the file_userPref.html test, we check that there is a user preference available to allow users to enable the browser to lock the pointer/mouse. It would drive a lot of people mad if this option isn’t available, right?

Next up is file_constantXY.html (we a nearly done), where we test that when the mouse is unlocked, the movement between a point (X1, Y2) to another (X2, Y2) is different. However, when the pointer is locked, all the values should equal to zero.

Finally, file_targetOutOfFocus.html, is used to check that an element can be locked even when it is not in focus. For example, in a page with two div element, and div1 should be able to lock the pointer even though div2 maybe the element in focus. This is not similar to file_exitMouseLockOnLoseFocus.html, where focus is shifted entirely to another document.

Whew!!! That was a long test, as of now, I made a pull request to be merged with Dave Humphrey and he will post a patch on Bugzilla.

[Updated] More tests!!!

The file_cursorPosEvents.html is a test to check that the “mouseover”, “mouseout”, “mouseenter” and “mouseleave” events can be executed prior and after pointerlock.

• They check that mozMovementX and mozMovementY are present in a mouse event object.
• It also checks that value of mozMovementXY and it should be equal to the current screenXY minus the last screenXY.

What’s Left?

Well we currently have one test that is commented out as it is throwing a bunch of weird errors. It is the file_MouseEvents.html. A possible problem that we can think of is that we cannot pin point the exact location of the mouse before the lock to synthesize it properly.

What’s Next?

What’s next? I will be most likely be making small changes that may have formatting issues from Dave and other such little problem. I will also be waiting for a review on the next patch. Until then, I can return to my attention on the bug that I worked on partially (Bug 601535)

**Updated: There is a weird crash that caused the test to fail. Read my blog about it here.

The longer you linger on a bug with no patch, the more changes you have to make as other people post their patch.

This made a lot of sense as other code patch may cause crashes on the section where I am working at. It feels like the “survival of the fittest code”.

Fixing the Code

Every developer (NOT programmer) have their own coding style. Something that is highly evident while reviewing other people’s code. This causes a problem with code readability and review and is one of the reason why all contributors to code for Mozilla must stick to a specific coding style. It is also the same reason why it took me a long time to figure out some of the test suite coded by other people.

I felt like someone threw the “painsaw” at me (a term I learned from Ed which is a combination of pain and chainsaw). The code have weird indentation and the flow does not seem right. It may pass or fail the test, depending on when the code was executed by the machine.

I was working with Raymond on the test suite. Let’s hope he is having a better time than me. While I continue to fix more of these problems.

Well for it’s obvious advantages.

• By working with more than one bug, I can divert my attention to another bug when waiting on one. It also helps me re-think and come to a possible solution when working on something else. Something like a Eureka! effect.
• I get to keep myself busy. I can often be quite restless and want to do random things. All these work keeps me busy.
• I can keep myself on the edge and help also improve myself.
• The little pay from the work helps pay for my bills at the bar and keeps me sane from all the stress.
• It is kinda fun doing it.

All these work also have their own disadvantages.

• It can be over-whelming at times. This means that it can affect my social life.
• You never know how much or big of a task is in front of you until you hit the snags. This applies to picking up more than you bargained for. (I don’t think I had hit that part of being over-whelmed yet; fingers-crossed)
• Very often you’ll be cursing and saying “I need 30 hour/day, 8 day/week to get this done!”.

So for the past few weeks I picked two bugs on bugzilla.

1. Bug 601535 - This is a refactoring bug, where I had to go through all the code in the content/media folder for cases where arithmetic operations can cause overflow and make use of a “helper class” called CheckedInt.h to check the overflow. (This bug was partly finished by Kyle Huey)
2. Bug 633602 – This is more of a continuation of what I did in the last four month. I will be continuing to contribute to the test suite (once a new patch on the mouselock core is reasonably done).

Building Firefox on Rome

On another topic, I just got my account on “Rome”. Rome is this really fast machine sitting in Seneca College that can truncate the time taken to build Firefox immensely. However, there is a problem when building on the Rome server ( big surprise there, NOT!!! ). This was caused mainly due to a missing pre-requisite for building Firefox on Linux.

Updated: The missing library is now fixed.

Here is a blog post for those who want to set up a ssh session to run builds. Note that the instructions applies to any user who wishes to build Firefox on some remote server of their own as long they have access to the server. Highly plausible scenario: users with slow Windows machine, ssh-ing to a fast Linux box to build Firefox.

So, I had started working on applying the patch that was landed by Kyle and I will be taking over the driver seat from there.

The last four months of 2011 had been really exciting while hacking on real open source code (this does not mean the first half was boring). I had actively contributed to the MouseLock API on Firefox, which is still a work in progress and I will continue further in polishing them out. However, that will be one of the project that I will be working on this semester. I hope to be able to spread out my scope and try to pick up other bugs as time pass.

More Possible Bugs

I do have this bug (Bug# 716107) that I got myself assigned to and I wish to work on it. I involved adding more keys to the fullscreen API such that there is no “Press ESC to Exit” warning whenever a user is interacting when the browser is in fullscreen mode. More to come on what I think about this bug.

I may be picking others bugs too. But, who knows. We shall see.

As part of my optimization, I was trying to recycle the canvas tag as running numerous test with their own canvas tag and scene object would demand high system resource. Additional technical details can be found on issue 21 of the issue tracker for CubicVR.

By recycling the canvas tag the code currently involves creating a new tag and initialising the CubicVR GLCore only once and every time a new test is to be executed, the scene object is recycled as well. As such, I was able to reduce the loading time that would occur between two test cases. [I also noticed that in Firefox 8, the webGL context seem to be performing faster than the older version]

Thus, every time when a test case finishes, the content of the canvas is copied as a DataURI source for an image tag. This means that the page becomes lighter and performs much faster.

I had attached the screenshot below and note that the test area is where the canvas lives now and the images below are img tag and not a canvas element:

Closing the Ticket

So what’s next? I feel this ticket is mature enough to be closed unless additional problems come up. I will be pushing up the code for review and once it is satisfied, the performance test should be ready for use. Now users could start timing their test on the Performance Test.

My code here (most of the changes are on the index.html):

https://github.com/Anachid/CubicVR.js/tree/issue21/tests/perf

So, for the last two days, I was struggling to get my MouseLock test working along with other test cases with Mochitest. In my earlier post, I mentioned how I managed to get the test running using Mochitest when I am running a stand-alone file. But the problem that I am facing now is that the test must run along with other file in test suite. It seem that the enable full screen through an iframe will cause the test to time out without running any test.

To summarize this blog, “I GOT IT WORKING!!”. Now, let me describe how I went about doing it.

When running all the test in a directory using mochitest, the test suite plugs them inside an iFrame (which is html frame tag), which holds each test files and executes them. iFrame does not support the full screen capability as such:

After some digging around, I found this Mozilla Developer Network document that explains that iFrames does not support the full screen as a standard feature.

However, with a lot of digging around I found that there was some other test that was done to solve this little obstacle with regard to full screen and took his code example (full credit to whoever coded those functions).

I had uploaded my code on github and note that this code is poorly formatted (worked on this late at night) and may be improved over time:

Github: https://github.com/Anachid/mozilla-central/tree/mouselock/dom/tests/mochitest/mouselock (look for the test_DOMtree.html and file_DOMtree.html file) [EDIT: look for the test_FullScreenHarness.html, moouselock_util.js and file_DOMtree.html]

The screenshot below shows my test working….YEEEE!!!! (sorry for “my test”, suck at MS Paint)