To get around that problem is very simple, below are listed the steps needed to get access to USB devices in the VM.

First, make sure you have the latest version of the software:
Download VirtualBox

You also need to install the extension pack:
Get Extension Pack

and the Guest Additions:

Guest Additions Manual

After installing all the extra dependencies, it is time to enable USB access to the VM.

First

Right click on the VM and select settings:

You will get this message:

Failed to access the USB subsystem

VirtualBox is not currently allowed to access USB devices. You can change this by adding your user to the ‘vboxusers’ group. Please see the user manual for a more detailed explanation.

It tells that you need to add your user to the vboxusers group.

Second

There are two ways to add users to groups in Ubuntu.
Via the GUI

If you want something faster, it is also possible to add a user to a group via the command line:

After adding the user to the vboxusers group you need to restart Ubuntu.

Third

Now after adding the user to the vboxusers group, it is time to select which USB device you want to mount in the VM

Forth

Access USB devices in the VM

More Info:
http://www.howtogeek.com/howto/31726/mount-usb-devices-in-virtualbox-with-ubuntu/

We already use Linode to host some of our projects, so we decided to host the nodejs project there as well.

All of our current projects are being served via apache.

The problem is that we can’t set apache and node to listen on the same port (80) and we didn’t have the option of deactivating apache to run just node.

We decided to implement a quick solution to get both apache and node working together: Proxy mode

So apache can still listen on port 80, and whenever somebody requests the nodejs application we forward the request to the port node is listening, in our case 11342.

Below are the steps needed to get apache and node running on the same server:

Assuming you already have apache2 installed and the nodejs application set up.

Load proxy modules

Load the proxy modules that will forward the request to node:
Open the file apache2.conf
Usually the file is located in the dir /etc/apache2/
If you not sure where the file is:

cd /
sudo find -name "apache2.conf"

After opening, append the following lines at the bottom of the file:

LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so
LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so

Without adding those modules, if you try to start apache you will get this message:

Syntax error on line 6 of /etc/apache2/sites-enabled/mysite.com:
Invalid command ‘ProxyRequests’, perhaps misspelled or defined by a module not included in the server configuration
Action ‘configtest’ failed.
The Apache error log may have more information.
…fail!

Configure the vhost

Now that you have the required modules running, it is time to configure the vhost

To add a vhost to apache you need to create a file in /etc/apache2/sites-available

<VirtualHost *:80>
     ServerAdmin your@email.com
     ServerName mysite.com
     ServerAlias www.mysite.com

     ProxyRequests off

     <Proxy *>
          Order deny,allow
          Allow from all
     </Proxy>

     <Location />
           ProxyPass http://localhost:11342/
           ProxyPassReverse http://localhost:11342/
     </Location>
     DocumentRoot /srv/www/mysite/public_html/
     ErrorLog /srv/www/mysite/logs/error.log
     CustomLog /srv/www/mysite/logs/access.log combined
</VirtualHost>

First you specify that all requests on port 80, to the domain mysite.com should be forward to localhost at port 11342

Enable the vhost

Now you need to enable the new vhost:

a2ensite siteName

A link will be created in the sites-enabled dir

to disable the site:

a2dissite siteName

Restart apache

Last thing you need to do is restart apache:

service apache2 reload

You should get the message:
* Reloading web server config apache2 [ OK ]

References:

http://www.ehow.com/how_5458585_configure-modproxy.html
http://karrigell.sourceforge.net/en/proxy.html
http://davybrion.com/blog/2012/01/hosting-a-node-js-site-through-apache/

Speaking with my brother in law, that now works in the same university as the teachers that created Lua, recommended to me a podcast where the main creator of Lua talks about the language in general.

The podcast is VERY good, Roberto Ierusalimschy explains why he created Lua, all the architectural design behind it, his philosophy regarding the project, some good use cases for the language and the future for Lua(the podcast is in Portuguese)

After listening to the podcast, I was really surprised to hear that Lua’s only data structure is Tables, much like the object notation in javscript, and that a lot of features in the new JS engines today are somewhat derived from Lua.
I decided to give a try and play a bit with the language.

Bellow is a simple tutorial to get Lua up and running on Ubuntu

Installing Lua

There are a few different ways you can install Lua on your machine, I decided to get the source code and compile it.
Lua it self is not that big, ~20,000 lines of code.

You can download the code here:

I downloaded the latest stable version, 5.2.0

After downloading/extracting, you’ll ge this files:

/doc
Makefile
README
src

All it takes to compile Lua is a simple:

make linux test

linux species which platform you want to build.
The complete list of supported platforms:

• aix
• ansi
• bsd
• freebsd
• generic
• linux
• macosx
• mingw
• posix
• solaris

test just prints the version of Lua to stdout

After compiling, the Lua executable will be created in your /src dir

To open the Lua shell: ./lua

*If you want to add the lua executable to your path there are several different ways to do it. A simple way is to create a symbolic link to lua in your $HOME/bin dir. It will automatically add lua to your PATH next time you log in

**You might get this error if you don’t have the readline lib installed:

To install the readline lib:

sudo apt-get install libreadline5-dev

After installing the lib, you should get this output:

If you don’t want to install the readline lib, you can make a few modifications to their build system:
Changing src/Makefile

linux:
  $(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX" SYSLIBS="-Wl,-E -ldl -lreadline -lncurses"

to

linux:
  $(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX" SYSLIBS="-Wl,-E -ldl -lncurses"

also removing the lib from src/luaconf.h

#if defined(Lua_USE_LINUX)
#define Lua_USE_POSIX
#define Lua_USE_DLOPEN    /* needs an extra library: -ldl */
#define Lua_USE_READLINE  /* needs some extra libraries */
#define Lua_USE_STRTODHEX /* assume 'strtod' handles hexa formats */
#define Lua_USE_AFORMAT   /* assume 'printf' handles 'aA' specifiers */
#define Lua_USE_LONGLONG  /* assume support for long long */
#endif

or just do a:

make ansi

More info here.

Running Some Programs:

To get started, lets run the famous Hello World program.
In Lua, all it takes is a simple:

print("Hello World!")

To run the program:

lua hello-world.lua

Another example using tables:

obj = {
  a = 1,
  b = {
    str = "b1",
    dec = 2.1
  },
  c = 3,
  f = function (x)
        return x*2
      end
}

for index,value in pairs(obj) do print(index,value) end

print(obj.f(2))
print(obj.b.str)
print(obj.b.dec)

Much like in javascript, you can create tables using the object notation: { }

You can think of tables as an associative array, a key value pair structure, just like a hash.

That’s very powerful and gives a lot of flexibility when writing programs.
You can create very complex data structures with a few lines of code.

Use Cases

The Lua project has more than 15 year of existence, being tested and used by several different companies

Adobe has more than 100 engineers working specifically with Lua.
The Adobe Light Room was mainly written in Lua.

Huawei, the second largest network and telecommunications equipment company in the world has more than 1 million lines of Lua written in their products

Some other well known projects that use Lua are:

• Wireshark
• Apache
• Redis
• VLC player
• + a bunch of others

The list of games is huge, close to a total of 160 different titles:

• World of WarCraft
• The Sims 2
• Star Wars
• Mafia ||
• L.A Noire
• Far Cry
• Crysis

You can check the complete list here:

Lua and the Web

What got me really excited about Lua, was the fact that it can also be used as a web server.
Actually, some benchmarks show that Lua can be up to 3 times faster than node.js and the VM is also a lot smaller than node.

There are a few projects that started porting Lua to be much like a nodejs server. Using the Lua VM instead of the V8 engine, but keeping all the awesome architecture existing in node

One of the projects is Luvit.
The project is still on its early stages of dev, but looks very promising

Other cool projects involving Lua:
LuaLibEvent
lua-ev
LuaNode
JSON4Lua
lunit

First, I want to talk about Firefox.
Last semester I had the opportunity to get started with Firefox developemnt.
The first bug I worked on was the PointerLock. We started hacking PointerLock last November, and I’m really happy to say that after 6 months of hard work it finally landed and it’s expected to ship on firefox 14. Thanks for everybody involved on the bug, it was an awesome experience
** You can find more info about the whole process of the PointerLock implementation here.
Now that it’s over, I realize how unique was this opportunity, and that was one of the reasons I kept pursuing it until the end. I learned so much and met so many smart people during the process that I’m glad to have chosen this path, and if I could I would do everything again.

Besides working on PointerLock, this semester for the DPS911 course I found some other bugs to hack.
This is a list of all the bugs I was involved during the semester:

• Bug 581863 – gtk2/nsWindow::GetScreenBounds returns client window size instead of outer (frame) size
• Bug 581866 – outerWidth / outerHeight features in window.openDialog do not include window manager decorations
• Bug 633602 – Implement Pointer Lock (Mouse Lock) API
• Bug 712225 – When element is in fullscreen mode, window.innerHeight is bigger than window.outerHeight
• Bug 715141 – Using keyboard to switch zoom level when viewing images directly
• Bug 718133 – Remove keyboard shortcuts for zooming to 1:1 scale when viewing standalone images
• Bug 713383 – Directly viewed images should be printed with a transparent background on the body
• Bug 713608 – HTML5 Video controls are missing in Fullscreen
• Bug 714071 – The Show Statistics setting is not preserved when toggling the full screen mode
• Bug 728893 – Allow mochitest iframe to go fullscreen
• Bug 724108 – Exception is thrown when showing statistics on a loading video
• Bug 735031 – Fullscreen API implementation assumes an HTML Element
• Bug 739874 – Input type “password” doesn’t receive Focus event with a mouse click

Status of the Bugs:

From the list above, the following bugs were landed:

• 633602
• 715141
• 718133
• 713383
• 714071
• 728893
• 735031

I’m still working on bugs:

• 581863
• 581866
• 712225
• 713608

and I filed bugs:

• 712225
• 728893
• 724108

Blog posts related to Firefox development:

Creating my first Firefox patch
Synthesizing mouse events in a mochitest
DPS911 Update
Firefox Bug 714071
Bug 713608 Update
Updating PointerLock API – Callbacks, Events and Threads
PointerLock API Updates
Bug 728893 – Allow mochitest iframe to go fullscreen
Bug 735031 – Fullscreen API implementation assumes an HTML Element

MongooseJS

Besides working on Firefox bugs, I worked on a bug on the mongooseJS library:

Ticket #718 – Add multiple validators to a Schema field
Solution

I wrote about the bug fix here:
MongooseJs Validators – Contributing to an open source project

Some other projects I worked during the semester:
Simple Drawing Application with ProcessingJS, part I

Visualizing algorithms using Processing.js

Visualizing algorithms using Processing.js , part II

What’s next?

• Finish the bugs I have started
• Find more bugs
• Keep hacking

One of the areas I want to get involved in Firefox is the SpiderMonkey Javascript engine
I also want to keep working on bugs related to the DOM and Events in general.

**Two readings that I really recommend:
History of Mozilla’s DOM bindings
New DOM bindings

Personally, I couldn’t be happier with the results.
I learned several things during the process, and most important, I was able to apply them in other courses as well.
For example:

• Git
• GitHub
• Mercurial
• IRC
• Bugzilla
• Blog
• Twitter
• Javascript
• OpenSource

GitHub

After being introduced to GitHub last semester on the DPS901 class, I was able to apply that knowledge and use github to contribute to some projects and to use on personal projects as well

GIT

One of the things I always here is that schools don’t teach students how to use version control systems, and that usually turns out to be a problem when looking for a job. Well, I’m very fortunate to say that I had an awesome introduction to GIT on DPS901 that showed me not only how to use the tools in a technical perspective, but also how to use to organize a project and optimize the development time.

Mercurial

Since Mozilla uses mercurial as its version control software I had to quickly learn how to use the tool. It wasn’t easy, but applying the concepts I learned last semester with GIT and with the help of the Mozilla community I was able to get started.

Bugzilla

I still remember a few years ago when I first went to Bugzilla searching for a bug  and being totally overwhelmed. First I couldn’t understand how Buzilla worked and second every bug that I looked could have been from another world as far as I knew. Everything seemed so hard, to be honest not only there was a lack of knowledge on my side, but also a lack of confidence  knowing that I could contribute to a huge project like Firefox. The funny part is that now, if I look at other bug trackers for big systems, such as chromium, eclipse, fedora, etc. I’m not afraid anymore, even though I might not know how the project works I have the confidence that I can just dive in and start contributing.

Javascript

Before I took the DPS901 course, I thought javascript was a language that validated forms in a web page, little I knew about how powerful javascript really is. I couldn’t have asked for a better introduction to the real power of javscript.
Thanks to the introduction to javascript last semester, this semester I was able to apply that knowledge in several different projects.
A few tools I used this semester:

• NodeJS
• MongoDB
• Jquery
• ProcessingJS
• Mongoose
• Other Node modules and client side javascript libs.

Blog

This semester I had to put a lot of things into perspective, one of them was Blogging. Before DPS901 and DPS911 I never stopped to think that writing about the work I did was really important, and I can see from talking with my peers at Seneca that they also think the same. However, after listening to David Humphrey lectures I realized that it doesn’t matter what work you do, if you are not able to talk about it and present to other people it’s almost as if you didn’t do it. Now a days living in a society that have such powerful communication tools it is a must to take fully usage of them. It is really helpful to have a place where you can go and see the work you did in the past, when I look back to my first blog posts I can see what I was working at that time and even use that as a reference for some work I might be currently doing, Plus the fact that if you recorded a problem/solution that you’ve faced, it could also be helpful to other people that are facing the same problem. How many times you didn’t search for something and ended up finding the solution in a blog?

Twitter

Another social tool I was introduced last semester was Twitter. Even though I still haven’t put in my routine to tweet about things, I use twitter regularly to see the work other people are doing and get in touch with the news around the world.
Twitter is an awesome tool that allows you not only to share with other people the work you’re doing, but also to keep updated with what is going on around you.
One of my goals for the summer is to become more active on twitter and start tweeting more often

Open source

In 2009, my first year in college I went to the FSOSS hold here at Seneca College. Since then, I knew I wanted to get involved with open source development. I’m a big believer in the open source way, and that it can be applied not only on software but in other parts of our society as well, but that’s a topic for another post.

One of the things that really made me happy this semester was to see open source in action in one of the projects I’m working on.
At the beginning of the project, one of the group members, a .NET developer was really skeptical about using NodeJS and MongoDB (both open source tools) in the project we were starting. After some good conversations he agreed and we dived into the challenge. During the way we had several road blocks, but every time we faced one I kept telling him that since all the tools we were using it were open source we could go and check the source code, and if we find a bug we could go and fix it, or change the code to do what we wanted, and that’s exactly what we DID!
The first project we contributed to was MongooseJS.
We faced a situation where we wanted to validate a Schema passing multiple validators during its initialization. However the library didn’t support that feature. We had two options in our hands:

• Move on and find another way to do it
• Add the feature we wanted to Mongoose.

We decided it was worth a try and opened a ticket on their repo on github: ticket
The we submitted a pull request with a possible fix: pull request
The solution was merged in their repo and now we and everybody else can use that feature

It was also good to see my brother in law building Firefox and starting to get involved with the project, and seeing some friends file bugs on Bugzilla and contribute to other open source projects.
Overall, I’m really happy to see more people understanding and getting involved in OpenSource projects.

To finish, I want to thank all my peers in the DPS911 course this semester, it was really inspiring to see the awesome work they did fixing bugs on Firefox and Popcorn.js

• Abhishek Bhatnagar (abhatnagar1)
• Christopher De Cairos (cadecairos)
• David Seifried (dseif)
• Matthew Schranz (mjschranz)
• Mohammed Buttu (mbuttu)
• Raymond Hung (rhung)
• Scott Downe (scott)
• Steven Ching Wei Tseng (Anachid)

And of course, a Big thanks to David Humphrey.
I couldn’t have asked for a better teacher and a better introduction to OpenSource and Firefox development.

Sincerely, Thanks for everybody, and lets keep hacking

An overview of the relationship between DOM Elements

This is not a complete diagram, there are a bunch more elements inheriting from nsIDOMHTML/SVG/XULElement. However, It gives a nice visual representation showing that not all DOMElements are HTMLElements.

Problem

Only HTML Elements were allowed to receive fullscreen mode.
SVG Elements didn’t know about mozRequestFullScreen since the implementation was done only for HTML Elements

Requesting mozFullScreen on a SVG element would give this error:

TypeError: svgElement.mozRequestFullScreen is not a function

The IDL declarion for mozRequestFullScreen was on:

And MozRequestFullScreen was implemented on:

Solution

The solution was to move the declaration of mozRequestFullScreen to:

And the definition:

Now both HTML and SVG elements can request fullscreen mode.

Notes

Since this fix had to change some IDLs, their UUID had to be updated. However, in this case, because the base IDL for all DOMElements was changed, the UUIDS for all the IDLs inheriting from nsIDOMElement had to be updated as well. The problem is that there are around 150 IDLs inheriting from nsIDOMElement, and to update each one by hand would have been CRAZY!
Luckly, somebody must have faced this problem before and created a script to update the UUID of IDLs and all its children.

To run the script:

update-uuids . nsIDOMElement nsIDOMDocument

The output:

  nsIDOMElement because it was given on command line
    f561753a-1d4f-40c1-b147-ea955fc6fd94 -> a652db92-f8d4-47e0-bf8f-1ad72e6c083f
  nsIDOMDocument because it was given on command line
    d7cdd08e-1bfd-4bc3-9742-d66586781ee2 -> ff3125e0-b1b5-467f-84ad-1d1eeafed595
  nsIDOMHTMLElement because it inherits from nsIDOMElement
    3de9f8c1-5d76-4d2e-b6b9-334c6eb0c113 -> 5b703ce7-e551-41fa-b465-ff94aa3bdc66
  nsIDOMXULElement because it inherits from nsIDOMElement
    5e0a7c2c-fdb6-459d-a67b-549181218c31 -> 42e74ec0-75c7-422c-b564-f853e3cbbb8b
  nsIDOMSVGElement because it inherits from nsIDOMElement
    dbb1b49c-dce5-43fe-97ea-e249b5620aa2 -> d2900917-e0ce-4eb8-aaf9-7e021d45472a
  nsIDOMXMLDocument because it inherits from nsIDOMDocument
    b53a4bab-0065-468b-810a-4c4659a04f00 -> b76ca016-46e8-4ee2-be3d-5b08b29afb72
  ....
  ...
  ..

Updated ./dom/interfaces/svg/nsIDOMSVGLineElement.idl with 1 changes
Updated ./dom/interfaces/svg/nsIDOMSVGStopElement.idl with 1 changes
Updated ./dom/interfaces/svg/nsIDOMSVGGElement.idl with 1 changes
Updated ./dom/interfaces/svg/nsIDOMSVGPatternElement.idl with 1 changes
Updated ./dom/interfaces/svg/nsIDOMSVGForeignObjectElem.idl with 1 changes
....
...
.
Originals are in *.idlbak

A Quick Overview on Mochitests

By default an iframe is not allowed to go fullscreen mode, and since all the mochitests are run inside and iframe, if one of the mochitest needed to go fullscreen it would not work (pointerlock for example)

There are two different ways to run mochitests. With runtests.py or mochitest-plain(ends up running runtests.py)

1. python ./obj-dir/_tests/testing/mochitest/runtest.py –test-path=dom/tests/mochitest/pointerlock
2. TEST_PATH=/dom/test/mochitest/pointerlock make -C obj-dir/ mochitest-plain

The first one calls explicit the runtests.py, that is the script that creates the http server
The second one will run mochitest-plain.
Now what is mochitest-plain?
First we need to look at the root’s Makefile
/Makefile.in
Line 129 is including testsuite-targets.mk, that’s where mochitest-plain is defined

127 ifdef ENABLE_TESTS
128 # Additional makefile targets to call automated test suites
129 include $(topsrcdir)/testing/testsuite-targets.mk
130 endif

mochitest-plain
Here is where mochitest-plain is defined, it calls $(RUN_MOCHITEST)

128 mochitest-plain:
129 	$(RUN_MOCHITEST)
130 	$(CHECK_TEST_ERROR)

RUN_MOCHITEST
In the end runtests.py is ran with some default flags

64 RUN_MOCHITEST = \
65 	rm -f ./$@.log && \
66 	$(PYTHON) _tests/testing/mochitest/runtests.py --autorun --close-when-done \
67 	  --console-level=INFO --log-file=./$@.log --file-level=INFO \
68 	  --failure-file=$(call core_abspath,_tests/testing/mochitest/makefailures.json)  \
69 	  $(SYMBOLS_PATH) $(TEST_PATH_ARG) $(EXTRA_TEST_ARGS)

**Running the tests with mochitest-plain will add some flags to the execution of runtest.py

[diogogmt@rome mozilla-central-diogogmt]$ TEST_PATH=dom/tests/mochitest/pointerlock/ make -C ff-dbg/ mochitest-plain
make: Entering directory `/home/diogogmt/mozilla-central-diogogmt/ff-dbg’
rm -f ./mochitest-plain.log && /usr/bin/python2.7 _tests/testing/mochitest/runtests.py –autorun –close-when-done –console-level=INFO –log-file=./mochitest-plain.log –file-level=INFO –failure-file=/home/diogogmt/mozilla-central-diogogmt/ff-dbg/_tests/testing/mochitest/makefailures.json –symbols-path=./dist/crashreporter-symbols –test-path=dom/tests/mochitest/pointerlock/

The flag –close-when-done is set by default. However sometimes you may want to leave the browser window open for debug purposes. I’m not sure if there is a way to tell mochitest-plain not run the runtests.py with the –close-when-done flag not set. What I usually do is run the tests calling directly runtest.py, since it runs withouth any flags, giving me more flexbility.

When not specifying a file, the mochitest will load all the files of the dir and run them inside the harness

For example:
dom/tests/mochitest/Makefile.in
The mochitest Makefile contains the list of the dirs of some tests

45 DIRS	+= \
46 	dom-level0 \
47 	dom-level1-core \
48 	dom-level2-core \
49 	dom-level2-html \
50 	ajax \
51 	bugs \
52 	chrome \
53 	general \
54 	whatwg \
55 	geolocation \
56 	localstorage \
57 	orientation \
58 	sessionstorage \
59 	storageevent \
60 	$(NULL

dom/test/mochitest/geolocation/Makefile.in
In the geolocation Makefile all the tests for that module are listed

41 relativesrcdir	= dom/tests/mochitest/geolocation
42
43 include $(DEPTH)/config/autoconf.mk
44
45 include $(topsrcdir)/config/rules.mk
46
47 _TEST_FILES	= \
48 		test_allowCurrent.html \
49 		test_allowWatch.html \
50 		test_cancelCurrent.html \
51 		test_cancelWatch.html \
52 		test_clearWatch.html \
53 		test_clearWatch_invalid.html \
54 		test_manyCurrentConcurrent.html \
55 		test_manyCurrentSerial.html \
56 		test_manyWatchConcurrent.html \
57 		test_manyWatchSerial.html \
58 		test_manyWindows.html \
59 		test_optional_api_params.html \
60 		test_shutdown.html \
61 		test_windowClose.html \
62 		test_timerRestartWatch.html \
63 		test_worseAccuracyDoesNotBlockCallback.html \
64 		geolocation.html \
65 		geolocation_common.js  \
66 		network_geolocation.sjs \
67 		windowTest.html \
68 		$(NULL)
69
70 libs:: 	$(_TEST_FILES)
71 	$(INSTALL) $(foreach f,$^,"$f") $(DEPTH)/_tests/testing/mochitest/tests/$(relativesrcdir)

From line 48 to 67 are listed all the test files
Line 41 is defined the path where the files are located
Line 71 is the path where the files will be copied after compiling firefox, for example:
/obj-dir/_tests/testing/mochitest/tests/dom/tests/mochitest/geolocation

Running single tests
When running the test as a stand alone, there is no need for an iframe, the test is loaded in the parent window, so the element is allowed to go fullscreen, different from when the tests are run inside the harness.

The Problem

When we first started writing mochitests for pointerlock we had to find a way to run the tests inside the harness while setting them to fullscreen.
The solution was to use the same approach as the fullscreen tests. To create a harness inside the harness, for example

Solution

The solution was simple, we just had to add the attribute mozallowfullscreen=true to the mochitest iframe.
However, there are three places where the iframe gets defined:

• server.js
• browser_harness.xul
• plain-loop.html

server.js is used for mochitest-plain
browser_harness.xul is used for mochitest-chrome and mochitest-browser-chrome
plain-loop remains a mystery

For server.js:

IFRAME({scrolling: "no", id: "testframe", width: "500", height: "300", mozallowfullscreen: "true"})

For browser_harness.xul

<iframe id="testframe" scrolling="no" width="550" height="350"></iframe>

You can find the complete patch here

Sanity tests

To make sure the mochitest framework works, before running all the tests a list of sanity tests is executed to test the framework itself.
You can see the list of the tests in the /testing/mochitest/tests/Makefile.in

43 relativesrcdir  = testing/mochitest/tests
44
45 include $(DEPTH)/config/autoconf.mk
46
47 PARALLEL_DIRS = \
48 	MochiKit-1.4.2 \
49 	SimpleTest \
50 	browser \
51 	$(NULL)
52
53 include $(topsrcdir)/config/rules.mk
54
55 _TEST_FILES = \
56   test_sanity.html \
57   test_sanityException.html \
58   test_sanityException2.html \
59   test_sanityWindowSnapshot.html \
60   test_SpecialPowersExtension.html \
61   test_SpecialPowersExtension2.html \
62   file_SpecialPowersFrame1.html \
63   $(NULL)
64
65 ifneq ($(OS_TARGET),Android)
66 # Disabled on Android for permaorange, see bug 688052
67   _TEST_FILES += \
68   test_sanityEventUtils.html \
69   test_sanitySimpletest.html
70 endif
71 # Copy the sanity tests into a subdirectory, so the top level is all dirs
72 # in the test screen.
73 libs:: $(_TEST_FILES)
74 	$(INSTALL) $(foreach f,$^,"$f") $(DEPTH)/_tests/$(relativesrcdir)/Harness_sanity

One thing to notice is the folder the sanity tests are copied to: Harness_sanity

After Firefox is compiled, all the tests are copied to /obj-dir/_tests/testing/mochitest/tests
So to run the geolocation tests for example:

• TEST_PATH=dom/tests/mochitest/geolocation

The Harness_sanity on the other hand:

• TEST_PATH=Harness_sanity

Since allowing the iframe to go fullscreen mode could break other tests we decided to add a check on SimpleTest.finish() to cancel fullscreen mode if the test forgets to cancel it

+    // Cancel element fullscreen mode due to Bug 728893
+    if (document && document.mozFullScreenElement) {
+        document.mozCancelFullScreen();
+    }

So now we needed a test to make sure SimpleTest.finish was actually cancelling fullscreen.
My first thought was to have two test files, test_fullscreen1.html and test_fullscreen2.html. On test_fullscreen1.html the element would be set to fullscreen mode and without cancelling call SimpleTest.finish(), then on test_fullscreen2.html would check the fullscreen status of the iframe, it should be false since SimpleTest.finish() supposed to cancel it.
However, there was an easier way to write the test, with just one file instead of two.

+
+
+
+  Test for Bug 728893
+<script type="text/javascript" src="/tests/SimpleTest/SimpleTest.js"></script>+<script type="text/javascript" src="/tests/SimpleTest/EventUtils.js"></script>
+
+
+
+<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=728893" target="_blank">
+ Mozilla Bug
+</a>
+</pre>
<div id="div">+</div>
<pre>
+</pre>
<pre id="test">+<script type="text/javascript">// <![CDATA[
+
+  /** Test for Bug 728893
+      Checks if SimpleTest.finish cancels fullscreen mode
+      The assertion happens after calling SimpleTest.finish
+      Running the test without the harness won't work
+  **/
+
+  SpecialPowers.setBoolPref("full-screen-api.enabled", true);
+  SpecialPowers.setBoolPref("full-screen-api.allow-trusted-requests-only",
+                                 false);
+
+  SimpleTest.waitForExplicitFinish();
+
+  var div = document.getElementById("div");
+
+  document.addEventListener("mozfullscreenchange", function (e) {
+    if (document.mozFullScreenElement === div) {
+      SimpleTest.finish();
+    }
+    else {
+      is(false, document.mozFullScreen,
+        "SimpleTest.finish should cancel fullscreen mode");
+    }
+  }, false);
+
+  function start() {
+    SimpleTest.waitForFocus(function() {
+      div.mozRequestFullScreen();
+    });
+  }
+
+
// ]]></script>
+
+
+

The assertion “is(false, document.mozFullScreen, “SimpleTest.finish should cancel fullscreen mode”);” is happening after SimpleTest.finish is called, the reason that it is possible to still make assertions after calling SimpleTest.finish is because the test itself is being run inside the mochitest harness

SimpleTest.js

678     if (parentRunner) {
679         /* We're running in an iframe, and the parent has a TestRunner */
680         parentRunner.testFinished(SimpleTest._tests);
681     } else {
682         SimpleTest.showReport();
683     }

Line 678 checks if the test is being run inside a harness, if true it goes to the next test, but it doesn’t terminates the current one.
Different from line 682 that call showReport, terminating the current test and displaying the results.

**Big thans to Clint(ctalbert) for all the help with this bug

Lets start with mochitests. While writing mochitests for pointerlock we stumbled on two problems

1. Not being able to specify how many tests should run (different platforms were running different number of tests)
2. Mochitest iframe not allowed to go fullscreen, making us run all the tests on a different window

David Humphrey came up with a solution for our first problem and added an “expect” functionality to the mochitest framework.
So now we can specify how many tests should occur when making asynchronous tests, for example:
SimpleTest.waitForExplicitFinish(3)
Bug 724578

For our second problem, I added the attribute mozallowfullscreen=true to the mochitest iframe that runs all tests.
I’m not sure if there was a specific reason for not allowing fullscreen on the mochitest iframe, but if it wasn’t it will simplify a lot writing tests for pointerlock
Bug 728893

Spec Updates

The spec had two major changes

1. Switching from callbacks to events
2. Moving functionality to the Document and Element

For example:
Everytime the pointer is locked/unlocked a mozpointerchange event will be dispatched to the document
A mozpointererror event will be dispatched if there are any errors while locking the pointer
Now It’s possible to access the element with the pointer locked via the document

var div = document.createElement("div");

document.addEventListener("mozpointerlockchange", function (e) {
  if (document.mozPointerLockElement === div) {
    // Pointer is locked
  }
}, false);

document.addEventListener("mozpointerlockerror", function (e) {

}, false);

document.addEventListener("mozfullscreenchange", function (e) {
  if (document.mozFullScreen &&
      document.mozFullScreenElement === div) {
      div.mozRequestPointerLock();
  }
}, false);

div.mozRequestFullScreen();

Instead of something like this:

var div = document.createElement("div");

div.addEventListener("mozpointerlocklost", function (e) {
  // Dispatched when pointer is unlocked
}, false);

document.addEventListener("mozfullscreenchange", function (e) {
  if (document.mozFullScreen &&
      document.mozFullScreenElement === div) {
      navigator.mozPointer.lock(
        div, // Element
        function () {
          // Success callback
        },
        function () {
          // Failure callback
        }
      );
  } 
}, false);

div.mozRequestFullScreen();

The work being done now is mainly some final touches, specially on the mochitests and on the API.

Recently the W3C PointerLock spec has been updated, the changes are the following:

• When locking the mouse, dispatch pointerlockchange/pointerlockerror events instead of firing callbacks
• Locking the pointer by requesting pointer lock on the target element
• Adding a reference to the locked element in the Document
• Exiting pointerlock by calling exitPointerLock on the Document

Those were significant changes, since it affected a big chunk of the code we had it implemented. However, I believe these updates to the API are beneficial, since with them developers will have an API similar to the fullscreen to work with.

The first bit I started working on was to dispatch the pointerlockchange/pointerlockerror instead of callbacks.

To Dispatch the events, the nsAsyncDOMEvent object was used:

static void
DispatchPointerLockChange(nsINode* aTarget)
{
  nsRefPtr e =
    new nsAsyncDOMEvent(aTarget,
                        NS_LITERAL_STRING("mozpointerlockchange"),
                        true,
                        false);
  e->PostDOMEvent();
}

Same logic to dispatch the pointerlockerror and pointerlocklost

One of the good things about having to go back and rewrite some code, is the fact that opens the possibility to analyse some of the decisions made before.
Specifically in this case, the use of different threads when locking the pointer.
At first, the callbacks were being fired on a different thread so the execution wouldn’t hang, and the Lock method would be able to return as soon as possible and not make the user wait for a result.

Before, the logic for callbacks was mainly based off the nsGeoLocation implementation. However, now with the pointerlock API looking more like the fullscreen api I went and looked how they handle setting the element into fullscreen.
I had written a blog post a while back inspecting the fullscreen API, so even with the API receiving some changes it was easy to locate the code path for requesting fullscreen on an element.

Here is a simple diagram I drew

The diagram shows that once mozRequestFullScreen is called on an element, the method returns really fast and all the heavy processing happens on a separate thread.

On the other hand, this is how PointerLock does it:

On PointerLock, different from the FullScreen, the heavy processing happens on the main thread, and the new thread only handles the callback firing. Now switching to events, even less processing happens on the new thread, so that made me rethink the logic for locking the pointer.

I remember hearing that all the code that involves changing the presentation, it needs to happen on the main thread, so maybe that’s why we’re not spinning the pointerlock check/validation to another thread, since it involves changing the UI presentation by hiding the pointer if the lock is successful.

Another thing that caught my attention was the fact that on the fullscreen code, the nsCallRequestFullScreen object was dispatched to a new thread using NS_DispatchToCurrentThread and on PointerLock we are using NS_DispatchToMainThread

NS_DispatchToCurrentThread
NS_GetCurrentThread
nsThreadManager::GetCurrentThread

NS_DispatchToMainThread
mMainThread

After working on Bug 714071 – The Show Statistics setting is not preserved when toggling the full screen that also involved working on the videocontrols.xml file, I thought would be good to keep digging how XBL bindings work on firefox.
So far Bug 713608 has proven to be more complicated than I thought it would be.
At the beginning, I followed the same logic used on Bug 714071 and tried to find the method that shows/hides the controls. However, different from the Statistics menu option, it seems that hiding the controls uses a different approach.
This is the code that displays the statistics of a video

showStatistics : function(shouldShow) {
                    if (this.statsInterval) {
                        clearInterval(this.statsInterval);
                        this.statsInterval = null;
                    }

                    if (shouldShow) {
                        this.video.mozMediaStatisticsShowing = true;

                        this.statsOverlay.hidden = false;
                        this.statsInterval = setInterval(this.updateStats.bind(this), this.STATS_INTERVAL_MS);
                        this.updateStats();
                    } else {
                        delete this.video.mozMediaStatisticsShowing;
                        this.statsOverlay.hidden = true;
                    }
                },

But I couldn’t find the equivalent method for the video controls.

Browsing through the code, I was able to find the methods triggered by the event listeners for mousemove/over/out used by the video element:

MouseMove

onMouseMove : function (event) {
                    // If the controls are static, don't change anything.
                    if (!this.dynamicControls)
                        return;

                    clearTimeout(this._hideControlsTimeout);

                    // Suppress fading out the controls until the video has rendered
                    // its first frame. But since autoplay videos start off with no
                    // controls, let them fade-out so the controls don't get stuck on.
                    if (!this.firstFrameShown &&
                        !(this.video.autoplay && this.video.mozAutoplayEnabled))
                        return;

                    this.startFade(this.controlBar, true);
                    // Hide the controls if the mouse cursor is left on top of the video
                    // but above the control bar and if the click-to-play overlay is hidden.
                    if (event.clientY < this.controlBar.getBoundingClientRect().top && this.clickToPlay.hidden) {
                        this._hideControlsTimeout = setTimeout(this._hideControlsFn, this.HIDE_CONTROLS_TIMEOUT_MS);
                    }
                },

MouseInOut

onMouseInOut : function (event) {
                    // If the controls are static, don't change anything.
                    if (!this.dynamicControls)
                        return;

                    clearTimeout(this._hideControlsTimeout);

                    // Ignore events caused by transitions between child nodes.
                    // Note that the videocontrols element is the same
                    // size as the *content area* of the video element,
                    // but this is not the same as the video element's
                    // border area if the video has border or padding.
                    if (this.isEventWithin(event, this.videocontrols))
                        return;

                    var isMouseOver = (event.type == "mouseover");

                    // Suppress fading out the controls until the video has rendered
                    // its first frame. But since autoplay videos start off with no
                    // controls, let them fade-out so the controls don't get stuck on.
                    if (!this.firstFrameShown && !isMouseOver &&
                        !(this.video.autoplay && this.video.mozAutoplayEnabled))
                        return;

                    if (!isMouseOver) {
                        this.adjustControlSize();
                        
                        // Keep the controls visible if the click-to-play is visible.
                        if (!this.clickToPlay.hidden)
                            return;

                        // Setting a timer here to handle the case where the mouse leaves
                        // the video from hovering over the controls.
                        this._hideControlsTimeout = setTimeout(this._hideControlsFn, this.HIDE_CONTROLS_TIMEOUT_MS);
                    }
                },

My plan was to find the event listeners that trigger the display of the video controls, then find how those events are added/removed to element.

I found where the listeners were defined

<handlers>
        <handler event="mouseover">
            if (!this.isTouchControl)
                this.Utils.onMouseInOut(event);
        </handler>
        <handler event="mouseout">
            if (!this.isTouchControl)
                this.Utils.onMouseInOut(event);
        </handler>
        <handler event="mousemove">
            if (!this.isTouchControl)
                this.Utils.onMouseMove(event);
        </handler>
    </handlers>

However, I couldn’t find where they are added/removed from the video element.

I feel that I’m getting close to finding a solution.

Big thanks to Jared Wein (jaws) for helping me with this and other bugs