Pointer Lock [Mouse Lock] API – Adding a Patch and the Troubles we got (0.2 Release)

This blog the Pointer Lock patch came out a little bit late, mainly, because I got sick the other weekend and I went to class to find out that I have this paper to write. The paper talks (or is going to, since I am almost halfway through it) about the internet sharing of research journals and the ethical and financial issues at stake.

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.

 

PointerLock [MouseLock] API Test – Part 2: Crashing the Test

This blog is a continuation of my previous blog on the PointerLock Tests and I initially didn’t even planned for a two part blog. This happened due to a failure of the test which caused it to crash.

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.

 

MouseLock API Test Update [0.1 Release]

Over the past week, I had been pushing myself to get the test for the MouseLock API up for review over the weekend or early next week. At the time of writing this blog, almost all the test are good to go. Like I just said, ALMOST!!

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.

 

Mouselock API Test – Fixing and Reviewing

This blog is a continuation of a series of blog on the test suite for the MouseLock API (For those new to this API, please refer to the API specifications). Sometime last week, Dave (Professor at Seneca College) posted a new patch to the MouseLock bug that had all the changes (I think) that was suggested by the reviewers. Now for the bad part, the new patch caused all our test cases to fail. This reminds me of the small note Dave suggested (the following were not his exact words, but somewhere on those lines):

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”.

 

Working on Bugs for Mozilla

If you read my previous blog post, I wanted to pick up bug 716107, which involved the suppression of warnings when users hit different keys when the browser is on fullscreen mode from a specific element. However, this bug proved too complicated for me to tackle. It does not only involve fixing code, it also involved haggling with folks from security as enabling new key strokes may open up other security bugs. (I DID cc myself on this bug and would like to see how they proceed, ).

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).

 

Running FullScreen on Mochitest

After finishing the test for my bug, our professor plugged all the test together and he crashed almost all the test in the mouselock directory (not surprising to me).

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.

 

Testing MouseLock with Mochitest

As I mentioned in my earlier blog, I started to contribute to the MouseLock API, which is a JavaScript API which will users to play “First Person Shooter” (aka FPS) games or other similar application using HTML5. For my most recent contribution, I was testing the MouseLock API with Mochitest, an automated test framework for regression testing used by Mozilla.

 

Contributing to Firefox MouseLock API

Just made a small fix to the MouseLock API for Firefox. It is pretty tiny in scale. For this bug, I made a small fix to handle the return errors appropriately. Let’s see if my fix is good enough to be adopted.

Currently, I am trying to understand how CubicVR handles mouse events. I might try to implement a primitive MouseLock feature with CubicVR. Let’s see how that works.

[Updated] It seem one of my classmate finished implementing the mouse lock with CubicVR’s first person level. Take a look for yourself: