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!