There’s been a lack of posts I must admit, much of it due to the lack of any real significant breakthroughs. Much of the progress has been minor ones which didn’t feel like they merited a post in itself. So now that a week has essentially come, a round up post is in order. As the title of the post suggests, much of this post will detail my experience while working on Windows.
There were three main things that were necessary to get the tests done (assuming that the tests from last semester were all pretty much perfect). The first was that the tests needed to be updated to use the proper syntax. This meant that lines that said
var pointer = navigator.pointer got changed to
var pointer = navigator.mozPointer. The second thing that needed to be done was to trim unnecessary tests. Several tests from last semester had tests that overlapped with each other, and in general, if it’s tested once and it works, don’t bother testing it again, it’s a waste of time. Lastly, one thing that was noticed by a few of the test developers from last semester were that there were leaks that were being caught by mochitest.
This last task was the most time consuming of them all and it ended up also being mostly a wasted effort. Much of the leaks actually occurred in the now defunct file_MouseEvents.html. As mentioned in my previous post, when I first found this, I was extremely exciting. It took ages to find this out. I had to cut files from the test harness one by one to find which file did it. Afterwards I had to lob of entire sections of the test to finally find the culprit, and then promptly learned that it was a Windows specific issue. Luckily, it turns out that we didn’t need to be that specific, which meant we could avoid the leak totally. By specific I mean that for Firefox, the route a mousedown event takes is for the most part is the same regardless of which button is pressed. So instead of sending a mousedown event for left, middle, and right mouse button, you can send a generic one and know that it will cover all three.
The next major work was to integrate into file_movementXY.html a test to check to make sure the mouse can theoretically move beyond the element in point lock. In other words, once in pointer lock, the mouse should be able to continue to move in any direction and not worry about hitting the “edge” of the browser which would, in normal circumstances, cause the mouse to stop reporting events to the browser. Original attempts were fairly straight forward. The test would move the mouse, store the mozMovementX and mozMovementY move it almost half the screen 3 times, and then check to make sure the values added up to be larger than the screen width or height (depending on if we’re comparing X or Y). On linux it flat out failed. Instead of getting a positive number, it seemed that we were getting the negative equivalent to what we were expecting. On Windows, it was worse. For the most part, running it would give the tests a pass (which was why I pushed to my repository for peer review), but if you were to move your mouse outside of the browser when the test started, the tests would fail and something similar to the linux error occurs… a negative number. It turns out, the test could be simplified and after a chat with Diogo the current method was developed. The idea was that by moving the mouse to the center and initializing pointer lock, we know that after each move we go back to the center of the screen. We would move a quarter of the screen each time, and when the moves are finished we can declare that it works. The reason is because if we try to use synthesizeMouse and send the mouse to a location beyond the browser, the test would hang and thus the test would fail.
More recently, work was being done on file_cursorPosEvents.html. This really highlighted a lack of understanding on my part regarding asynchronous calls and events. I’m too used to coding in C and C++ with synchronous calls and often times I make the incorrect assumption that certain things are synchronous when they’re not. In such cases, we’re looking at possible random fails. Another poor habit includes not using a bool when all I use a variable for is to track if something happened or not. With this test, I’ve also found that working running pointer lock tests on Windows is wonky at best…
I’m sure we need to test these on Windows, however, so far it seems that whatever runs on Linux works on Windows. More interestingly is that, whatever doesn’t work Linux, still has a chance to work “as expected” on Windows. As I showed Diogo on Tuesday, while movementXY would fail on linux, and it would succeed with no problems on Windows. This has caused me and my colleagues a lot of headaches (namely because I push it up to my repo for review because it works for me… just not for them). However, to really highlight the “what the heck”-ness of developing on Windows, take a look below. The following screenshots were taken right after a pull and compile. No files were changed that could alter the behaviour.
The image above shows that for the most part, everything is A-OKAY! We have 1 todo left and this bunch of tests are good. It should be noted that there should actually be one fail. This failure is consistent with macs and linux computers when they run the same set of tests. So there seems to be a missing error… but that’s not all. Right now we’re in a specific test, however, if I were to go up one level …
As you can see, test_FullScreenHarness actually DOES have a fail. To clarify, the order in which this occurred, I actually started out in the folder view and then went into run test_FullScreenHarness to see what was actually failing. The important thing to note is by running test_FullScreenHarness, we actually LOST a test. It didn’t all of a sudden succeed, it just skipped it. Another reason for concern is that the number of tests total up to 76. The actual number of tests that are supposed to be there is 80. The number of tests for mozPointerLock is correct, which means in the tests are missing in test_FullScreenHarness.
We’re very close to finishing up the tests, the last one is to fix file_cursorPosEvents.html. The purpose is to make sure that once in pointer lock, mouseover, mouseenter, mouseout, mouseleave events are no longer triggered. After a lot of iterations of the file and consulting with Steven, we’re still somewhat stumped as to how to do this properly. At the moment, if you were to run this test, the set of tests will occur twice. This is because the mousemove that is directed to the child is redirected to the parent, which is why the tests happen twice. A solution was proposed to directly send to the child mouseover, mouseenter, mouseout, and mouseleave events to the child. In this case because those events are essentially eliminated, there’s nothing to signify to us that it’s “okay to check if the events occurred now.” The idea to circumvent that was to use setInterval or setTimeout… which probably won’t fly which means we’re still at the drawing board.