Mozilla Firefox #6

The last two weeks were pretty awesome!

Since the last post I’ve been working on some tests for about:networking, there still is some more work to do, but they look promising.

In the first week I hit a big wall of documentation because I never developed tests on mozilla platforms. Don’t worry I didn’t get hurt, I managed to understand how those platforms work and by the end of the week I finished the implementation of 3 tests for the http, dns and sockets features. It wasn’t that difficult, I had to be a little careful because we have a lot of asynchronous calls in those features, but the XPCShell harness has some nice ways to deal with this kind of situations.

After that I tried to implement a test for the websockets feature, but in the XPCShell documentation I read it wouldn’t have given me a window to use the WebSocket API and therefore I resort to another harness, Mochitest. This kind of tests has a big overhead, but it was the only way I could test this feature. There still was a little problem: I had to write a little python websocket server because our tests shouldn’t rely on external services.

These first four tests landed about two days ago and are ready to protect the dashboard against any harmful code.

Currently I’m trying to test the ping diagnostic tool. Things got a little more complicated with this test, there are a lot of callbacks within async calls and my mind is spinning like the event loop because I don’t understand why a local http server blocks my test refusing to close itself.

I asked the module owner for an advice about separating this test from the others because I found out there is a nsIServerSocket interface which implements a server socket that can accept incoming connections and it really works, but running this test beside the others, under these circumstances, causes an interference between them.

I hope to get an answer soon and solve this problem. I will notice you next post!

Mozilla Firefox #5


For the past weeks I’ve been taking advantage of the Networking Dashboard integration in Firefox and I’ve fixed some bugs in the graphical user interface.

In the first week after the last evaluation we received a mail from the module owner with some suggestions about the GUI. He wanted for us to add some JavaScript to make our table’s data sortable by clicked column header. I stepped in and took this bug so I came out with a simple solution, not the most efficient, but I think is the most suitable for our situation:

A listener on the table headers gives me the index of the clicked column in the table, I take the table rows, put them into an array and using the JavaScript Array.sort() method, along with a particular comparison callback, the table becomes sorted by the clicked column.

This method is not that efficient because it takes the already rendered table, sorts it and renders it again (is the best solution when we sort an already rendered table, but when we want to keep the sorting order between table refreshes?) . Rendering a table is pretty expensive so my reviewer advised me to sort the data before first render, thus only a sort and a render operations will take place when refreshing.

This was a little bit trickier because I had to sort in parallel some arrays stored in a JS object. I figured out a solution would be to sort the array corresponding to the sorting column and, with a special comparison callback for the sort function, cache the results of the comparisons. The others array in the object will be sorted with a comparison callback which only returns the cached results. It works great, but there are some problems which make me wonder if it’s worthed, now I’m waiting for feedback.

Another bug I filed focuses on the refreshing feature. Initially, the refresh button and the auto-refresh checkbox request the new data for all the existing tabs. This problem was causing a lack of performance, especially with the auto-refresh feature, so I fixed it. Valentin came with a very good idea of letting the refresh button requests data for all the tabs, in case one wants to make a snapshot of all data on a specific moment of time, and the auto-refresh checkbox request data only for the active tab. It’s done and landed in trunk.

Between these bugs I discovered a crash in the dashboard’s menu, it was leaked by me when I helped Valentin with the integration:D, it’s now fixed.

Our next goal is to land some tests for the dashboard. Those were some fun weeks, see you next post!

#4 Mozilla Firefox


The last two weeks I worked on some Telemetry bugs. For the first one I had to report whether or not the DoNotTrack privacy feature was used and if it was, which option was selected by the user.

I started with a patch which was reporting the specified data even if the user was toggling between the options, I sent it and asked for feedback, but I was very sceptical about its behavior, the way it was approximating user’s choices and I decided to search for a way to report that data once-per-sesion. It wasn’t that difficult, I called the telemetry stuff in the nsHttpHandler destructor, but we were not sure if  the data would be actually reported because the same time HTTP was shutting down, so I put some breakpoints and I saw the destructor was called in the right time. The patch landed a few days ago and I hope the numbers will help the DNT developers.

After that, I started working on another bug, it was supposed to report the HTTP connections utilizations. I had begun with the first two tasks, how often a backup connection is created and how often this backup is never used, then looking through the code I realized there was a lot of work, a lot of new concepts…therefore I stuck right in the middle of it. I lost a lot of time understanding the code, the algorithms used there were not documented anywhere but some comments. I am glad I did that because, with the help of my mentor and the community, I learned a lot of new things and some great strategies, one of which I will present you next, it’s called “happy eyeballs”.

“Happy eyeballs” it’s an algorithm which can support dual-stack applications, both ipv4 and ipv6 are supported. Firefox does not implement the classic strategy, it has some small changes which I managed to understand from bugzilla discussions and code comments. In a simplified version, a primary connection is created with the first preferred version of IP, a 250ms timer starts. If the connection establishes before the timer expires, then no backup is created, else a backup connection is born with an IPv4 address, for everyone of them input/output streams are attached. After the backup is created, Firefox listens for an output stream “ready” event, thus the connection with the first stream ready is used.

That’s how my last two weeks went, tomorrow I will try finish this last one bug then we will continue working on Networking Dashboard, maybe we will write some unit tests.

#3 Mozilla Firefox


These weeks I focused on finishing the patches I had sent before, so Ping Diagnostic Tool is now reviewed+ and is waiting for landing. Along with it is a bug that was at the top of our stack because it was affecting the both diagnostic tools which me and Catalin had implemented.

This bug consists in a method that maps a NS_ERROR code to a string, more specific, NS_ERROR_OUT_OF_MEMORY error code is mapped to “NS_ERROR_OUT_OF_MEMORY”. We started with 2 ideas: a dictionary holding the (key, #key) pairs and an array of {key, #key} structures. We kept the second one because the hashtable was filling at runtime and this didn’t give us the expected level of performance. So, I began working on this method and I faced a really big problem, some of the error codes (some pseudo ones) was not unique within the Necko module and our method was returning unexpected results. I filed a bug with this problem and I sent a patch with unique error codes, but we gave up the idea because the module owner decided is not a thing to mess with, it has a lot of problems without localization and, to be honest, some tests crashed.

My work was not useless because out mentor had a great idea of constructing a second array with the duplicated codes and iterating firstly through this one, we get the desired results.

After this fight, I worked on tracing some data. We wanted to know how many bytes Firefox sent and how many it received. At that moment, the Networking Dashboard was keeping evidence of the data transferred through each active socket, but after the socket closed we didn’t know nothing about that amount of data. So, I created two bytes counters as members of the nsSocketTransportService class and, on every socket detach, the counters were updated. In the Dashboard class, I combined this counters with the existing tracing variables and now, about:networking has an improved data tracing feature.

By the time last week finished, I had taken a Telemetry bug and I warmed up for this week. This was very educative, I refreshed my knowledges about creating a new histogram and I found out that Firefox has a feature called DoNotTrack (shame on me, it shipped a long time ago) which lets you express a preference not to be tracked by websites. The guys wanted to know if usage measurements from telemetry line-up with their expectations and if anyone actually opts for “Yes, I want to be tracked”. I’ve sent a patch and now I’m waiting for a feedback because I’m not so sure if I understood right the behaviour they expect.

For each one of these features I’ve implemented some basic UIs for debugging purposes and some demos.

It was a great month, I’ve learned a lot of stuff and tricks (# and ## macro operators w0W!) and I’m eager for next evaluation and beer meeting.

Mozilla Firefox – #2 -

It’s my second post since the programme started and I have to say that I’m very excited about how things are going, we’ve learned a lot about our project and I think the way we approach new problems shows that.

Since my first post I’ve been working on a diagnostic tool, a transport layer ping meant to reach a server over the tcp/ssl protocol and give relevant information about the connection status to the user (reached, timed out, etc). I had a slow start, I didn’t even know how to begin, where from or how this feature should work, but I kept learning, documenting and with the help of our mentor and the community I’ve almost finished it.

I’m gonna present you a basic use-case, which I also received it from Patrick, the module owner, to understand better how this feature works:

Firefox says “cannot reach server“; I wonder why that is?


  1. Can I change to an IP address? (DNS lookup, Catalin is working on it)
  2. Can I connect to IP address port 443?(TCP ping)If not, why not?(refused, timed out)
  3. Can I handshake with SSL on port 443? If not, why not? (bad SSL version, invalid certificate, timed out, etc)

I started with actually doing the connect and reporting whether it worked or not and I recently finished to implement some timeouts for those connections whose status is never “reached”, so now the user can set a timespan before the connection is declared “timed out”. I’m currently facing a problem with mapping some error codes to localized strings. A method has a behaviour I haven’t expected so I’m now waiting for an answer from someone who already worked with that interface.

That’s all about how my work was going, I hope to find a solution for this problem until tomorrow.

See you next post!

First Week – Mozilla Firefox

Hi, my name is Robert Bindar and I am glad to take part in RSoC 2013.

Our project consists of two parts: the first one is a Firefox feature meant to provide a dashboard that monitors network activity and the second one is a system of histograms whose goal is to expose relevant informations about Firefox’s network performance, both of it very useful for developers.

After this summer I am confident the Networking Dashboard will be better, it will expose more information like the protocol version, TCP half-open connections and it will be more useful for developers with its new diagnostic and debugging tools.

The first week was fun! For the first three days I met with my colleague Catalin Iordache and our mentor Valentin Gosu at the university where we talked about the project, we studied the code and we also implemented some features like exposing the protocol version and half open connections.

We begun the second week with some documentation, we had a lot of questions for Valentin and the other module owners, but now we have a certain direction to make for implementing some diagnostic tools like Ping and DNS lookup.

It’s a good start and I’m confident we will stick to the plan and fulfil our mission.