Bug 735031 - Fullscreen API implementation assumes an HTML Element

Bug 735031 was to update the Firefox fullscreen implementation to allow SVG elements to receive fullscreen mode.

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.


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:

dom/interface/ html /nsIDOMHTMLElement.idl



was implemented on:



The solution was to move the declaration of mozRequestFullScreen to:


And the definition:


Now both HTML and SVG elements can request fullscreen mode.



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.

update-uuids 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

Bug 728893 - Allow mochitest iframe to go fullscreen

Bug 728893 was encountered while implementing PointerLock.

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

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

128 mochitest-plain:
130 $(CHECK

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

65 rm -f ./[email protected] &&
66 $(PYTHON) _tests/testing/mochitest/runtests.py –autorun –close-when-done
67 –console-level=INFO –log-file=./[email protected] –file-level=INFO
68 –failure-file=$(call core

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

[[email protected] mozilla-central-diogogmt]$ TESTPATH=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:
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

In the geolocation Makefile all the tests for that module are listed

41 relativesrcdir = dom/tests/mochitest/geolocation
43 include $(DEPTH)/config/autoconf.mk
45 include $(topsrcdir)/config/rules.mk
48 testallowCurrent.html
49 test
50 testcancelCurrent.html
51 test
52 testclearWatch.html
53 test
54 test
55 testmanyCurrentSerial.html
56 test
57 testmanyWatchSerial.html
58 test
59 testoptionalapiparams.html
60 test
61 testwindowClose.html
62 test
63 testworseAccuracyDoesNotBlockCallback.html
64 geolocation.html
65 geolocation
66 networkgeolocation.sjs
67 windowTest.html
68 $(NULL)
70 libs:: $(
71 $(INSTALL) $(foreach f,$^,"$f") $(DEPTH)/

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:

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


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 is used for mochitest-plain
browser_harness.xul is used for mochitest-chrome and mochitest-browser-chrome
plain-loop remains a mystery :P

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
45 include $(DEPTH)/config/autoconf.mk
48 MochiKit-1.4.2
49 SimpleTest
50 browser
51 $(NULL)
53 include $(topsrcdir)/config/rules.mk
55 _TEST
56 testsanity.html
57 test
58 testsanityException2.html
59 test
60 testSpecialPowersExtension.html
61 test
62 fileSpecialPowersFrame1.html
63 $(NULL)
65 ifneq ($(OS
66 # Disabled on Android for permaorange, see bug 688052
68 testsanityEventUtils.html
69 test
70 endif
71 # Copy the sanity tests into a subdirectory, so the top level is all dirs
72 # in the test screen.
73 libs:: $(TESTFILES)
74 $(INSTALL) $(foreach f,$^,"$f") $(DEPTH)/tests/$(relativesrcdir)/Harnesssanity

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:

  • TESTPATH=Harnesssanity

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, testfullscreen1.html and testfullscreen2.html. On testfullscreen1.html the element would be set to fullscreen mode and without cancelling call SimpleTest.finish(), then on testfullscreen2.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  
 + 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();  
 + });  
 + }  


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


 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

PointerLock API Updates

A quick update on the Firefox PointerLock API implementation

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:
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) {  
 }, false);


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) {  
 div, // Element  
 function () {  
 // Success callback  
 function () {  
 // Failure callback  
 }, false);


Updating PointerLock API - Callbacks, Events and Threads

The PointerLock implementation of Firefox is going great, we are close to having the patch ready to land, maybe Firefox 13.

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,  

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 NSDispatchToCurrentThread and on PointerLock we are using NSDispatchToMainThread

nsThreadManager::GetCurrentThread NS_DispatchToMainThread

Bug 713608 Update

One of the bugs I’m currently working on is: Bug 713608 – HTML5 Video controls are missing in Fullscreen
A quick overview of the bug:
This bug involves working with html5 video controls.
The goal of the bug is to enable the stock controls when the video enters in fullscreen via the context menu. For example: the controls are hidden when the video isn’t in fullscreen, then the user right clicks on the video and selects enter fullscreen. When the video switches to fullscreen mode, the controls will be displayed, even though they weren’t before toggling fullscreen, and after exiting fullscreen mode, if the controls were disabled in the first place, disable them again.

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) {  
 this.statsInterval = null;  

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

 this.statsOverlay.hidden = false;  
 this.statsInterval = setInterval(this.updateStats.bind(this), this.STATS_INTERVAL_MS);  
 } 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:


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


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

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


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


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

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

 if (!isMouseOver) {  

 // Keep the controls visible if the click-to-play is visible.  
 if (!this.clickToPlay.hidden)  

 // 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

 if (!this.isTouchControl)  
 if (!this.isTouchControl)  
 if (!this.isTouchControl)  

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