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 – The Networking Dashboard. Week 8 and 9

Hi,


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

Hi,

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!

Mozilla Firefox – The Networking Dashboard. Week 6 and 7

Hi,

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!

#4 Mozilla Firefox

Hi,

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.

Mozilla Firefox – The Networking Dashboard. Week 4 and 5

Hello,

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 ( http://www.janbambas.cz/firefox-detailed-event-tracer-about-timeline/ ). 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!

#3 Mozilla Firefox

Hi,

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 – 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: https://wiki.mozilla.org/Necko/Dashboard. 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 – #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 https://foo.com“; I wonder why that is?

Troubleshooting:

  1. Can I change foo.com 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.