Mozilla Firefox – The Networking Dashboard. Week 8 and 9


Over the past two weeks I’ve finally been able to finish my Proxy Settings Test Diagnostic Tool patch. This took me a while because of the response lag of my request for feedback and review to Patrick Mcmanus ( the owner of networking module). I found out that he was a little bit busy so I don’t blame him. Anyway, in this two weeks he was very responsive and we’ve managed to create a good patch.

First off all, there was a function (AsyncResolve()) for which I didn’t ask myself what would happen if it failed. So I’ve fixed that with a simple IF statement. After this he brought to my attention another problem – there was  a Cancel object (nsiCancelable) which wasn’t used in d’tor and this created a leak in Firefox, because it sometimes remained an outstanding request. In order to cancel that object in d’tor, I had to see first if that wasn’t null, and if so I’d simply use a cancel function on it.

The next problem that was pointed, created some problems for me. Firstly, I should say that the Mozilla code isn’t about the quantity but for the quality of it. That being said, for every Dashboard functionality that we want to implement, we create a new structure. This all have a callback object because of the async functions, threads and interaction between JS and C++ code. However at the beginning of functions, if demands it, we firstly initialised the callback object with the callback of the demand, and if a function would fail, we simply made that object null and returned a  fair result. Patrick thought that it would be better if I first made that object null, and at the end of function, before returning  a positive response, I would initialise it. It looks simple, and so it was, but after I did that, at every attempt for a proxy test, Firefox would SIGSEV (segmentation fault).  It took me a while, and Patrick was surprised when I pointed him the problem – it seems that OnProxyAvailable function (the function which creates the dictionary for JS) was being called from AsyncResolve() stack, and I was differentiating callback in that function. He said that he didn’t think that was possible for our API, but here it was. In order to get over this segmentation fault, I initialised callback object before AsyncResolve() function was called.

For me it was a surprise, because another async resolve function, which I have used in DNS Lookup tool, was working perfectly – but this was because the implementation of that function was different. There were a couple smaller problems and also the fact that I had to use an assert function at some point – which for me was a first; I didn’t know what an assert function would do, but it turned out that this function will terminate the program, usually with a message quoting the assert statement, if its argument turns out to be false – a thing that is quite useful.

Because of this important changes that I had done, I decided to file another bug for my DNS Lookup tool (which is already in Mozilla Core code base) in which I’ve modified it and now it is a lot safer and good looking :) .

However, there is another catch. In order for my proxy tool to be accepted in Mozilla Core code base, it had to have also a frontend. I thought that this would be one of the last things to do for our project, but because of some regulations that were presented to me by Patrick, I’ve started working not only for proxy but also for dns tool UI. I’ve managed to create some basic interfaces – for which I am still waiting for a feedback from Tim Taubert.

Another thing on which I had worked on was a bug filed by Valentin (our mentor). It seems that in its current state, the Networking Dashboard is not thread safe and it can’t even be called from the same thread multiple times (if the previous call hasn’t ended). He managed to implement a new function which creates a runnable event with a given argument – after this will be accepted it will help other projects as well. I had to make use of this new function, modify a lot of implemented functions, instantiate structures in .cpp files not in headers and other things too. So far I’ve worked over socket, http and web socket data. I’ve decided to stop working on it because it is an important and also a big patch and I want to apply changes over all code – so I’m waiting for my other two implementations to be accepted first.

This is what I have been working on for the past two weeks. For the upcoming weeks I want to start implementing some test (xpcshell files) for our dashboard and also add the functionality which will test the reachability of a proxy.

See you next time!

Mozilla Firefox – The Networking Dashboard. Week 6 and 7


The Networking Dashboard has been finally included in Mozilla Core code base. In order to see it, you will have to get Firefox Nightly, but I would recommend patience. The product is far from being final. We still have a lot of work to do. We are pleased because this has finally happened and also for the support that we already see it in people which are reporting bugs (not many though :) ).

So in this two weeks I haven’t been able to continue my work on Proxy Settings Test Diagnostic Tool because apparently Patrick (owner of networking module) had a lot of work to do and we were waiting for his review in order to know what I should modify or if my work is good so far.

I’ve started to work on logging bug, but after a few days me and Valentin realised that it is more complicated than we had expected. Also we found out that there are a few developers that are already working at something similar. I will get in touch with them and see if I can help them with something (I’d love to).

I have continued working at some UI futures and I’ve also got prepared for mid term.

About our meeting at ROSEdu – well, what can I say? it was a lot of fun. We were pleased with our presentation and the game of bowling afterwards.

Not a lot had happened in this two weeks but I’m glad that I’ve been able to get a little break.

See you next post!

Mozilla Firefox – The Networking Dashboard. Week 4 and 5


Over the past two weeks a lot of things have happened. We had the first evaluation and also a big part of Networking Dashboard it’s almost at an end.

Let’s start with 4th week. Robert, Valentin and I met at the university were we continued working at dashboard and also talked about what we were supposed to do over the next coming weeks. Also we have prepared for the evaluation presentation by putting all the patches over the code, testing all functionalities and establishing what we were going to talk about.

About the presentation we were feeling pleased. Also it was pleasing to see all the other students talking about their projects. I really didn’t know so much until the actually evaluation was held. The aftermath beer and the discussions were good and interesting :)

The next few days that were left of the week Valentin and I decided what I should do next. Of course I had to implement the last diagnostic tool: Proxy Settings Test but what we also wanted to do is to move to the next part of the project – Tracing/Debugging. The main idea here was to implement Honza Bambas’s about:timeline add-on ( ). Unfortunately Honza had other plans with his work, but we weren’t discouraged by this. So, after this, we established that I should get working at proxy settings test diagnostic tool, help Valentin at an older patch that he had worked on – about logging ( Bug 801209 ) and also working some more at Javascript code for UI.

Last week I had only managed to implement Proxy Settings Test Diagnostic Tool – filed as Bug 898237; as DNS Lookup tool, the implementation isn’t ready for a review because I had to wait for Robert’s error bug to be accepted first, in order to use it’s functionality to complete both my diagnostic tool patches. The functionality of this tool was already tested and works at it supposed to do.

The implementation was by far the most interesting because I learnt so much. First of all, the only complain that my mentor had for me at first evaluation was that I wasn’t talking enough with people from Mozilla. So for this patch I decided to first ask them for help, and after talk to Valentin. Also, the implementation itself consists in modifying two .webidl files, one .idl file and some work in C++. This was the easiest part. The hard part was to search for the correct service, functions, headers and idl files.

At the end, as I already said, the tool is working beautifully. The code looks good. I can’t wait to show it at mid term.

Now, I have to start working at logging bug and ask people from Networking module for more functionalities that the Dashboard should have, and also get working at UI.

See you next post!

Mozilla Firefox – The Networking Dashboard. Week 2 and 3

Our project at Mozilla Firefox consists of four parts: Information to Display, Diagnostic Tools, Tracing/Debugging and Progress and Ideas, which are presented in more details here: As you already know from my previous post, in the first week me and Robert worked at Information to Display, where we covered all tools except Cache status, and this is because there are other developers who are working at another project which involves modifying it almost entirely, so for now we are expecting the final product in order that our work won’t be in vain.

Over the past two weeks me and Robert Bindar worked at Diagnostic Tools. After talking with my mentor, Valentin Gosu, I’ve decided to work at DNS Lookup tool and Failed URL test, but after a quick chat with Patrick McManus, the owner of networking module, we have decided not to implement Failed URL test anymore, because it was basically an http level test and developer tools have grown to the point where they support that really well.

The DNS Lookup tool works similar as a a resolver DNS, a tool I’ve learned during communication protocols classes. You can say that the notion wasn’t new for me, but I think working at this diagnostic tool, healped me a lot. First of all I had to know that whatever I was supposed to do, it had to be an interaction between Java Script and C++. So I created a function (requestDNSLookup in an .idl file) that would be called from JS. In cpp I’ve implemented this function that at the end will call an async function that did worked like a resolver, which at the right time on the right thread will fill up the parameters of another function – OnLookUpComplete. For this I had to create another dictionary in an .webidl file and a structure in cpp, so the result of the async resolver could be stored. After this it was just a case of – take the information that you need and do whatever you need to do with it.

It may not sound like much, but believe me it takes a lot of time to understand how it all works. I’ve learned about async functions and also how Java Script and C++ interactioned one another. Also, after all the compilation error were resolved, we had to see if the result is the expected one, so for these I had to learn more about Java Script (because until now I didn’t code in it) to be able to create objects that finally show us what we want.

It’s been almost four weeks from the moment this programme started and I think that after the first three weeks I can say that me and Robert are ahead of schedule and most important, with the help of our mentor and hard work, we’ve been able to learn a lot of new things, which I know that will be helpful in the next comming weeks.

See you next post !

Mozilla Firefox – The Networking Dashboard. Week 1

Hello, my name is Catalin Iordache and I am working on a Mozilla Firefox project – The Networking Dashboard, which is a project that is meant to offer the same functionality as chrome://net-internals. Some of the functionalities are already implemented, but there is more to be done. Also because Mozilla has two projects in RSoC, this means that there are two of us that are currently working, and this will be me and Robert Bindar. Valentin Gosu, who is our mentor, had the excellent idea, that it is more productive and good for us if we will be helping each other.

This isn’t my first time working on Mozilla Core code base, because I did already contribute some patches I few months back in the Upstream Challenge competition, at University Politehnica of Bucharest. I have to say that, resolving a simple bug it is one think, but working on a big project like this, it is another.

Therefore, this is how the first week went:

For three days, Robert and I met at the University and studied the code. We first looked at some functionalities that were already implemented and which are needed to be exposed later which are RTT(Round Trip time or ping time) and TTL(Time to live) and also did some documentation about SPDY Protocol and Half-Open Connections, two of the functionalities that were needed to be implemented. While studying the code, I noticed a small error, so I fixed it (Bug 887566).

After two days and two meetings with our mentor, Robert and I implemented the functionality which will allow us to display if a connection is using SPDY Protocol and also which version it is using (spdy/2 or spdy3). For this we made changes in nsHttpConnection.h, nsHttpConnectionMgr.cpp, NetDashboard.webidl and Dashboard.cpp. This changes were submitted by Robert as a bug on Bugzilla (Bug 888267).

After this, we established what I have to do for the coming weeks and we left Bucharest for a more peacefully place to work (our homes). During the weekend I did more research about half open connections and after this I set about implementing this functionality. Now, the Networking Dashboard will be able to display for every host which sockets are haf opened and how many of them there are. I filed the implementation on Bugzilla (Bug 888628).

To work on Firefox is turning up to be very addictive, which I think it is a good thing.

Have a nice day!