Last week, the Firefox front-end team got together in Toronto to discuss various of our ongoing projects, with a special focus on performance-related goals. The performance team also joined us as there are various joint projects between our teams. After the week is over it’s interesting to look back and see what was accomplished during the week and what it opened as guidance for our future work. Here is my personal recap, some of the highlights of what I did and what I saw during the week. In no particular order:

• Finally met with Irving, with whom I’ve been working in the past few months in our project to move the Add-ons Manager storage from SQLite to JSON and making it off-main-thread (bug 853389, bug 853388)
• We did a triage of performance-related bugs to classify them into high impact and low impact and figure out where to focus
• Got to see some of the great progress that Tim Taubert and Avi has done on the tabstrip animations and got Tim to help me use the reflow observers to do some experiments of my own in the UI. I didn’t find any obvious low hanging fruits, which is expected since he has fixed various offenders since introducing these reflows observers, but the attempt was worthwhile
• Using the profiler I noticed some long stacks for text reflowing during tab animations, but these didn’t translate into any measurable slowness. In any case, I started some hacking to see if it was possible to improve it anyway. The issue is that the title in a tab has to be constantly remeasured for cropping while a tab opening animation is happening. I wrote a patch to only display the tab title and favicon after the animation has completed, and then got together with Avi to run his tab animation FPS tests and see what changes. The answer was: not much, there were no visible gains. In hindsight, there’s an obvious reason: even though we can hide the text in the tab that is opening, we can’t do it for the other open tabs, which will all be potentially shrinking and re-cropping at the same time. However, the investigation was very useful nonetheless, because we discovered two issues with the APIs used to measure the FPS on Mac: a telemetry measurement have been inactive since OMTC has been activated; and the framerate was always stuck on vsynced even with different values for layout.frame_rate (which is useful to tweak when doing animation stress tests)
• Got together with Paolo to discuss the plans and current state of the Downloads API off-main-thread project, which I’ll be joining to help (starting with bug 852482)
• Watched Vladan present his findings about running Firefox on an SD card. I had already seem the video through his blog post but watching it again and going into more details was very interesting, as the extreme slow disk IO is not only an artificial case produced on SD cards, but also something that many users have to face daily on machines with older hard drives and anti-virus software than can significantly worsen the problems.
• Vladan’s talk was also of particular interest to me as it serves as motivation and validation for the work I’ve been involved with in the last significant number of months: the Add-ons Manager work and now the Downloads API.
• And various converstations about Electrolysis, including a good talk with Yoric to understand how the ongoing work on session restore and e10s will interact

And beyond that there were also various other topics that benefited from having the team all together in one place, specially Social API and Australis. To me personally the week was immensely helpful as a motivator and as a way to get consensus and clarity into our upcoming projects, not to mention the fine chance of directly interacting with the entire team which not often happens as we’re all spread around the around!

As a side note, this blog post was an exercise in itself as one of the outcomes for me from the Summit Assembly meeeting we had at the week before. There’s more on it that needs a separate blog post to explain, but a personal action that I’ve taken from that event is to increase the transparency and involvement with the community about the work I do.

The Google Summer of Code 2013 project is about to get started: today the application submission period officially starts (and is open until May 3). Mozilla is again a participating org, and students can find a list of project ideas and application advice in our Summer of Code wiki page. It’s important to remember that the list on the wiki is for possible ideas, but students are not limited to those on the list: project proposals with your own ideas are also welcome. With this disclaimer in mind, I’d like to describe in a bit more details some of the projects that we from the Firefox team have included on the list, and to answer some of the more frequent questions that we have received through e-mail and IRC about them. If you’re a student interested in one of those, read on. I wrote a blog post for each of them:

• Silverfox
• Fullscreen mode
• Autosuggest search engines
• about:memory for real people

To make a good proposal, it’s important to keep in mind the goals and non-goals of the project, to demonstrate that you’ve understood how to approach the implementation of the project, and that you’re capable of doing so. It’s also important to create a solid schedule of deliverables that are used both to guide the steps of the project and to validate the pace and the progress up until that point. I’ve already written enough about the specifics and there’s a lot of content out there explaining what makes a good candidate and a good proposal, so i’ll keep this post brief.

Just as a last note, if you’ve sent us e-mail or pinged us on IRC, please be patient because we’re not online all the time or available to immediately reply, and so far we have seen a lot of interest in GSoC, so it takes us a while to reply to everyone’s emails. We hope that these blog posts will help more students to clarify some common questions about our proposals. Good luck to everyone, and remember that you’re always welcome to contribute to Mozilla, during the Summer of Code and every other season too 😀

about:memory for real people

This entry is part of a series of posts about some of our proposed GSoC projects. See here the introduction blog post.

What is it: about:memory is a tool that is used by Firefox developers to diagnose and understand the memory usage behaviors of the browsers. It has been immensely useful for us to find bugs in the MemShrink project and validate the fixes to those bugs. However, it is too focused on Firefox’s internals for the browser developers, but the available data there could be presented in different ways to also help web developers and regular users who wants to understand how each website consumes memory.

Example use case: User opens the new about:memory and sees that website A (tab 1) is taking 15mb and website B (tab 2) is taking 12mb. After 30min, the user opens the tool again, now to see website A still taking 17mb and website B taking now 30mb. They then can conclude that website B is consuming more memory as time passes, while website A is able to maintain its memory requirements steady.

What does it involve:

• looking into the current about:memory and understanding the existing data available and its breakdowns
• proposing various different ways to visually present that data and interact with it (e.g., sorting, time slicing, merging tabs from the same domain, animating data over time, etc.)
• proposing an existing open-source JS dataviz graphics library to be used for the project
• interact with the Firefox developers who work on memory optimization and provide feedback for more data that would be useful if it were available
• should be done as an add-on using the Add-on SDK

Non-goals: This project will not remove the existing about:memory, but will create a new one. Also, you should not try to create your own graphics library as part of the project, as there’s not enough time available to do both things during the official schedule.

Where to start: You should start by looking into the current about:memory and its code and to understand how data is retrieved from the memory measurements code. You then need to analyze the available data to undestand its meaning and start thinking on how you want to present that in a more visually interactive way. The usage of the Add-on SDK will also be required but will be very limited to packaging and setting up the add-on, as the main code will be a simple html page that implements your new about:memory (along with its supporting CSS and JS files).

Skills needed: JavaScript and CSS skills, and experience with data visualization. Experience with one JS graphics library would be great.

What is expected in your project proposal: A great understanding of the project, its goals and non-goals, and a good idea on how to approach each of the features involved and how to time slice them. A proposal for at least 4 different ways to visualize the data, describing what type of graphs will be used and the possible interactions that it will provide. The selection of the graphics library to be used. Links to open-source code (e.g. a github profile) that you have produced (specially ones involving data visualization).

Silverfox

This entry is part of a series of posts about some of our proposed GSoC projects. See here the introduction blog post.

What is it: Silverfox is the codename of a feature that we would like to have in Firefox. This feature changes the browser configuration options to focus on beginner users, in an attempt to prevent these users from mis-configuring the browser by accident, either by accidentally clicking on things, changing settings without understanding them, or by being directed by websites to change prefs or to install add-ons.

Example use case: Tech-savvy family member configures a new computer for relatives, installs Firefox and sets appropriate settings and add-ons to their liking, and installs Silverfox after to prevent less tech-savvy family member from breaking their browser.

What does it involve:

• changing the preferences window by hiding or disabling advanced or dangerous features, and displaying an explanation to the user on why those are disabled,
• disallowing changes in about:config
• preventing changes to the homepage url and preventing other add-ons to be installed
• preventing toolbars from being hidden or broken through customization
• provide an API for new features to be supported by Silverfox without the need for changes in Silverfox itself
• should be done as an add-on using the Add-on SDK

Non-goals: It is important to understand that Silverfox is *not* a security feature, and it should not try to prevent itself from being disabled or uninstalled. Quite the opposite, it should educate users on why it’s activated and why changing prefs is problematic. It should not try to disable existing add-ons or resetting prefs that have already been changed. It should also not prevent Lightweight themes from being changed, or blocking add-ons from being updated.

Where to start: Your main first step will definitely be to learn how to use the Add-on SDK and to generate add-ons using it. After that, you should familiarize yourself with the preferences.xul file and the other files from the same folder referenced inside it, and understand the XUL structure there (using the DOM Inspector add-on will also help you a lot). You’ll also need to see the about:config file, and others that can be learned as the project advances.

Skills needed: Great JavaScript and good CSS skills. Also having created add-ons and worked with the add-ons SDK will be very helpful.

What is expected in your project proposal: A great understanding of the project, its goals and non-goals, and a good idea on how to approach each of the features involved and how to time slice them. A proposal for good and non-intrusive UI that will be displayed for users of Silverfox, and how to handle the main interactions that will be created (but do not spend most of your proposal describing UI instead of the technical aspects of the project). Links to open-source code (e.g. a github profile) and/or add-ons that you have produced.