Firefox Bug 784402, Pointer Lock must respect iframe sandbox flag

Recently I’ve worked on the Firefox Bug 784402 – Pointer Lock must respect iframe sandbox flag.

This is a quick overview of what had to be done on the bug.

Sandbox flags

First lets check what the sandbox attribute does:
A quote from the w3c spec

The sandbox attribute, when specified, enables a set of extra restrictions on any content hosted by the iframe. Its value must be an unordered set of unique space-separated tokens that are ASCII case-insensitive. The allowed values are allow-forms, allow-popups, allow-same-origin, allow-scripts, and allow-top-navigation. When the attribute is set, the content is treated as being from a unique origin, forms and scripts are disabled, links are prevented from targeting other browsing contexts, and plugins are secured. The allow-same-origin keyword allows the content to be treated as being from the same origin instead of forcing it into a unique origin, the allow-top-navigation keyword allows the content to navigate its top-level browsing context, and the allow-forms, allow-popups and allow-scripts keywords re-enable forms, popups, and scripts respectively.

With pointerlock landing on Firefox 15, it was decided that a new sandbox flag should be created to restrict the pointerlock usage on embedded scripts in a page, so for example: if you add an advertisement script on your page, you don’t want to give the permissions to the advertisement to lock the pointer to itself.
To manage that, the allow-pointer-lock sandbox was created.

An overview of how the sandbox flags work:
List of flags:

/**
 * This flag prevents content from navigating browsing contexts other than
 * the sandboxed browsing context itself (or browsing contexts further
 * nested inside it), and the top-level browsing context.
 */
const unsigned long SANDBOXED_NAVIGATION  = 0x1;

/**
 * This flag prevents content from navigating their top-level browsing
 * context.
 */
const unsigned long SANDBOXED_TOPLEVEL_NAVIGATION = 0x2;

/**
 * This flag prevents content from instantiating plugins, whether using the
 * embed element, the object element, the applet element, or through
 * navigation of a nested browsing context, unless those plugins can be
 * secured.
 */
const unsigned long SANDBOXED_PLUGINS = 0x4;

/**
 * This flag forces content into a unique origin, thus preventing it from
 * accessing other content from the same origin.
 * This flag also prevents script from reading from or writing to the
 * document.cookie IDL attribute, and blocks access to localStorage.
 */
const unsigned long SANDBOXED_ORIGIN = 0x8;

/**
 * This flag blocks form submission.
 */
const unsigned long SANDBOXED_FORMS = 0x10;

/**
 * This flag blocks script execution.
 */
const unsigned long SANDBOXED_SCRIPTS = 0x20;

/**
 * This flag blocks features that trigger automatically, such as
 * automatically playing a video or automatically focusing a form control.
 */
const unsigned long SANDBOXED_AUTOMATIC_FEATURES = 0x40;

/**
 * This flag blocks the document from acquiring pointerlock.
 */
const unsigned long SANDBOXED_POINTER_LOCK = 0x80;

Parsing the flags

So we have a 32 bit integer to store the sandbox flags.

Breaking down the integer we have 8 bytes
We can represent each byte in hexadecimal format:

So the number 0xFFFFFFFF has all the bits turned ON

Knowing that, we could use each bit of the integer to represent a flag.
We don’t care about the decimal value of that integer, since we are using it to store flags and not values.
So by saying 0×1, we are telling to turn the first bit of the first byte on, 0×2 turns the second bit of the first byte on
0×10 on the other hand tells to turn the first bit of the second byte on.
Remember that we are using hexadecimal notation.

So in the end, what’s happening is that each flag is turning a different bit on the integer

Later we’ll be able to check if that specific bit is ON or OFF and determine the status of the flag.

One thing to keep in mind is that if the iframe doesn’t have the sandbox attribute, then all the flags are turned OFF by default.

<i frame></i frame>

If the iframe has an empty sandbox attribute, then all the flags are ON by default

<i frame sandbox=""></i frame>

To turn the flags off, you can specify the feature you want to enable in the sandbox attribute:

<i frame sandbox="allow-pointer-lock allow-same-origin></i frame>

In the snippet above both the allow-pointer-lock and allow-same-origin flag would be turned OFF, all the other flags would be ON

This is the code that parses the sandbox flags:

/**
 * A helper function that parses a sandbox attribute (of an <iframe> or
 * a CSP directive) and converts it to the set of flags used internally.
 *
 * @param aAttribute    the value of the sandbox attribute
 * @return              the set of flags
 */
uint32_t
nsContentUtils::ParseSandboxAttributeToFlags(const nsAString& aSandboxAttrValue)
{
  // If there's a sandbox attribute at all (and there is if this is being
  // called), start off by setting all the restriction flags.
  uint32_t out = SANDBOXED_NAVIGATION |
                 SANDBOXED_TOPLEVEL_NAVIGATION |
                 SANDBOXED_PLUGINS |
                 SANDBOXED_ORIGIN |
                 SANDBOXED_FORMS |
                 SANDBOXED_SCRIPTS |
                 SANDBOXED_AUTOMATIC_FEATURES |
                 SANDBOXED_POINTER_LOCK;

  if (!aSandboxAttrValue.IsEmpty()) {
    // The separator optional flag is used because the HTML5 spec says any
    // whitespace is ok as a separator, which is what this does.
    HTMLSplitOnSpacesTokenizer tokenizer(aSandboxAttrValue, ' ',
      nsCharSeparatedTokenizerTemplate<nsContentUtils::IsHTMLWhitespace>::SEPARATOR_OPTIONAL);

    while (tokenizer.hasMoreTokens()) {
      nsDependentSubstring token = tokenizer.nextToken();
      if (token.LowerCaseEqualsLiteral("allow-same-origin")) {
        out &= ~SANDBOXED_ORIGIN;
      } else if (token.LowerCaseEqualsLiteral("allow-forms")) {
        out &= ~SANDBOXED_FORMS;
      } else if (token.LowerCaseEqualsLiteral("allow-scripts")) {
        // allow-scripts removes both SANDBOXED_SCRIPTS and
        // SANDBOXED_AUTOMATIC_FEATURES.
        out &= ~SANDBOXED_SCRIPTS;
        out &= ~SANDBOXED_AUTOMATIC_FEATURES;
      } else if (token.LowerCaseEqualsLiteral("allow-top-navigation")) {
        out &= ~SANDBOXED_TOPLEVEL_NAVIGATION;
      } else if (token.LowerCaseEqualsLiteral("allow-pointer-lock")) {
        out &= ~SANDBOXED_POINTER_LOCK;
      }
    }
  }

  return out;
}

First all the flags are turned ON.
Then it checks if the sandbox attribute has any values, if it does it splits them and compares against the possible flags.
Once it finds a match, it does a BIT NEGATION on the flag and a BIT AND with the integer that has all the other flags.
What happens is that the flag being parsed is turned OFF.

In the end the integer with the status of all the flags is returned.

Locking the pointer

Now lets take a look at the code that checks for the allow-pointer-lock flag when an element requests pointerlock

bool
nsDocument::ShouldLockPointer(Element* aElement)
{
  // Check if pointer lock pref is enabled
  if (!Preferences::GetBool("full-screen-api.pointer-lock.enabled")) {
    NS_WARNING("ShouldLockPointer(): Pointer Lock pref not enabled");
    return false;
  }

  if (aElement != GetFullScreenElement()) {
    NS_WARNING("ShouldLockPointer(): Element not in fullscreen");
    return false;
  }

  if (!aElement->IsInDoc()) {
    NS_WARNING("ShouldLockPointer(): Element without Document");
    return false;
  }

  if (mSandboxFlags & SANDBOXED_POINTER_LOCK) {
    NS_WARNING("ShouldLockPointer(): Document is sandboxed and doesn't allow pointer-lock");
    return false;
  }

  // Check if the element is in a document with a docshell.
  nsCOMPtr ownerDoc = aElement->OwnerDoc();
  if (!ownerDoc) {
    return false;
  }
  if (!nsCOMPtr(ownerDoc->GetContainer())) {
    return false;
  }
  nsCOMPtr ownerWindow = ownerDoc->GetWindow();
  if (!ownerWindow) {
    return false;
  }
  nsCOMPtr ownerInnerWindow = ownerDoc->GetInnerWindow();
  if (!ownerInnerWindow) {
    return false;
  }
  if (ownerWindow->GetCurrentInnerWindow() != ownerInnerWindow) {
    return false;
  }

  return true;
}

The ShouldLockPointer method is called every time an element requests pointerlock, the method does some sanity checks and makes sure everything is correct.
To check for the allow-pointer-lock sandbox flag, a BIT AND with the mSandBoxFlags and the SANDBOX_POINTER_LOCK const is performed, we’ve looked at the SANDBOX_POINTER_LOCK flag before, it has the value of 0×80
So if pointerlock is allowed, the mSandboxFlags would have the SANDBOX_POINTER_LOCK flag OFF and the BIT AND would be false.

A big thanks to Ian Melven.
Ian is the one who implemented the sandbox attribute on Firefox and gave me some guidance on the PointerLock sandbox attribute bug.


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.

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:

dom/interface/ html /nsIDOMHTMLElement.idl

And MozRequestFullScreen was implemented on:

content/html/content/src/nsGenericHTMLElement.cpp

Solution

The solution was to move the declaration of mozRequestFullScreen to:

dom/interfaces/core/nsIDOMElement.idl

And the definition:

content/base/src/nsGenericElement.cpp

Now both HTML and SVG elements can request fullscreen mode.

Bug
Diff

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.

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

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


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


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


Firefox Bug 714071

Working on Bug 714071 introduced me to another layer of Firefox.
So far all I’ve been doing was working with c++ code, specifically related to the MouseLock API.
Bug 714071 on the other hand was focused on the js layer.

A brief summary of the bug:

Fix a problem with the Statistics video control


When the showing statistics option of a video was on, and the fullscreen was toggled the video would stop displaying the statistics but the menu would not be updated.
The goal for the bug was to keep showing the statistics when toggling between fullscreen.

The code that displays the statistics on a video is the following:

                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;
                    }
                },

Everytime the video was loaded on the page, or toggled in fullscreen, the init method would be called and an event listener would be attached to listen for the “Show Statistics” option click. However, the init method would initialize the video with a fresh config, so if the statistics were being displayed it would be hidden after switching between fullscreen mode.

Solution

The solution was to add a check on the setUpInitialState method to activate the statistics on the video if they were being displayed before toggling the fullscreen.

if (this.video.mozMediaStatisticsShowing) {
  this.showStatistics(true);
}

That apparently solved the problem and the statistics are preserved even when toggling fullscreen.

Working on this bug made me very curious. How could some javascript code interact with c++ at run time.
I knew about the XPCOM object model used in Firefox and lately I’ve started to read more about XUL and the Gecko engine . This was the perfect time to start digging more deep and learn more about the Firefox foundations.
Using the videocontrols as a starting point I went to mxr and started searching some code.
From my initial search I think I found where the controls were loaded in c++. Now I just need to figure it out how all that happens :)

videoscontrols.xml – define the video controls

nsCOMPtr mVideoControls;
nsVideoFrame::CreateAnonymousContent – where the menu gets attached to the video element

nsNodeInfoManager – apparently used to load the video controls as well the poster image
nsNodeInfoMangager::GetNodeInfo – looks like the loading happens here

Manage XPCOM objects?
PL_HasTableLookup
PLHasEntry
PL_HasTableAdd

NS_TrustedNewXULElement – where the XUL element gets created and casted to an nsIContent
NS_TrustedNewXULElement declaration
NS_TrustedNewXULElement definition

TODO:
Keep digging and find how the pieces fit together!


Debug Build of Firefox on Ubuntu

Following the tutorial on MDN  and with the help of the #developer channel on IRC I was able to build firefox in debug mode.
These are the steps I followed to get the build working:

Install dependencies:

apt-get build-dep firefox
apt-get install mercurial libasound2-dev libcurl4-openssl-dev libnotify-dev libxt-dev libiw-dev mesa-common-dev autoconf2.13 yasm

Create .mozconfig file in the root of your project

. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/ff-dbg
ac_add_options –disable-optimize
ac_add_options –enable-debug
ac_add_options –enable-tests

Then

make -f client.mk build

It took me around 1h 10min to finish the build

To run firefox:

cd ff-dbg/dist/bin
./firefox

**
For some reason, when I start the browser, after a few seconds it goes to sleep and crashes

Also if I try to run the firefox-bin I get this error:


Follow

Get every new post delivered to your Inbox.