Posted by: felipe | April 22, 2013

Summer of Code project – Fullscreen mode

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

Fullscreen mode

What is it: Many users express the desire to have a more immersive mode where screen space is a very important aspect to maximize. This mode would have all the browser fundamental controls in a single row at the top of the screen, leaving everything else for the webpage. This means that the Back button, the URL bar, the tab strip and the new tab button would all be in the same row, along with some other important information that is useful to have when a software is running in fullscreen mode (like a clock). We have had a preliminary mock-up for a while and it is the starting point for this project.

What does it involve:

  • A curved and clipped back button at the left corner of the screen
  • A sliding forward button that works just like the existing one
  • A button to access Firefox’s menu, based on Australis
  • The address bar should be a fixed width. The tabs should flex to fit the remaining space.
  • A clock and possibly other indicators such as wi-fi signal that can be obtained using the WebAPIs
  • Interaction with the UX team to evolve the mockup into the final design
  • The work to be done by the student during this project should be an implementation of this feature in one of our 3 desktop platforms (Windows, Mac or Linux)
  • The patches produced should get at least to the point of having review started on them, and should provide a good basis for the implementation on the other 2 platforms
  • Should be done as patches to the Firefox codebase

Non-goals: This project will not implement the curved tabs that is seen in the mockup, as that is part of the Australis project. It will also not involve producing the background page shown in the screenshot, of course.

Where to start: You should start by learning how to download Firefox’s source code and to successfully compile it in your platform, and also learning how to generate a patch using Mercurial. After that you should get used to the important source files related to this project: The structure of the browser window, some structural CSS used in all platforms, and the platform-specific ones (Win + Win, Mac, Linux). A tool that will be immensely useful is an add-on called DOM Inspector, which we urge you to download and explore the structure and CSS of the main Firefox window (specially when in Fullscreen mode). You should also look into the Firefox UX branch to see what the current state of Australis is.

Skills needed: Amazing CSS skills and an understanding of the new CSS flexbox model will be useful.

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. Mentions of the main XUL elements of Firefox’s toolbars (during fullscreen mode) and how they are displayed the way they are with the existing CSS, and suggestions on how to put them all in the same row and style them towards the look and feel of the mockup. Links to open-source code (e.g. a github profile) and/or add-ons that you have produced.

Advertisements
Posted by: felipe | April 22, 2013

Summer of Code project – Autosuggest search engines

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

Autosuggest search engines

What is it: Firefox supports adding new search engines to the search bar through the OpenSearch standard. You can see an example of it working by visiting bugzilla.mozilla.org and clicking the dropdown icon in the search bar: you’ll notice in the menu there’s an entry for “Add Bugzilla@Mozilla”. However, there are various search websites that does not present themselves as OpenSearch cabable, and thus they don’t get a chance of being added as a search option. But we can be smarter and detect these websites, and then also present them as an “Add <website>” for our search feature. We need, however, to be careful in our detection to not suggest websites with other types of forms, such as information fill-in forms, login forms, etc., and for that we need to come up with smart criteria to when we should consider a website as search-capable.

What does it involve:

  • Initial proposal for an algorithm (a set of criteria) to decide if a form in a website is a search form or not. This form will be obtained at the moment the user submits a query through it
  • Hypothesis testing of said algorithm against a number of example websites found by the student. The sample should contain websites that we want to detect as search capable, as well as websites where we want to detect it as not search capable
  • Implementation of said algorithm using JavaScript
  • Retrieval of necessary data from Firefox’s form history database (SQLite), as well as storage of extra data needed by the algorithm that is currently not collected by form history (e.g. the website URL)
  • Support for running the algorithm at an appropriate time and marking the site as search-capable for future visits
  • Presenting the site in the “Add <website>” menu in future visits if it has been marked as search-capable
  • Respect privacy choices such as Private Browsing and Clear Search Data
  • Should be done as patches to the Firefox codebase, and ideally in the project timeline the patches should end up in a close-to-review+ state with tests included

Non-goals: This project does not include any modifications of the current search UI, it’s only meant to provide the backend service to detect search websites without OpenSearch support. The algorithm should not involve any crowdsourcing or interaction with the user. No popups or prompting to the user will exist upon detection. This is a stepping stone that will provide better functionality and it can be surfaced in more relevant ways in the future when we rework our search functionality (or right now by using add-ons that improve it).

Where to start: You should start by learning how to download Firefox’s source code and to successfully compile it in your platform, and also learning how to generate a patch using Mercurial. After that you should get used to the important source files related to this project: formSubmitListener.js catches the action of submitting a form, which is the hook for the data collection of the algorithm. nsFormHistory.js contains the code that stores and retrieves form history data to the database. You should also look into the file formhistory.sqlite that exists inside your Firefox profile to see what data is stored and see what you can use and what is missing (you can use the SQLite Manager add-on to open that file).

Skills needed: Great JS and SQL skills, and a good understanding of how HTML forms works on the web and how they are used out there in real websites.

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. The algorithm that you propose (it will be iterated during the course of the project), and a rationale behind it. Supporting information that you understand all the data that needs to be stored (e.g. which new fields or tables will be necessary in formhistory.sqlite), how to store it and analyze it. Example websites (at least 4) and how your criteria will behave on them. Links to open-source code (e.g. a github profile) that you have produced, specially ones involving JavaScript and SQL.

Important note: This project has been very well received so far and lots of students having been asking questions about it and are going to submit a proposal for it. Please remember that due to GSoC guidelines and limitations, there’s only one student who can be picked up for the project, so please understand that a lot of proposals are coming in and don’t be discouraged if you’re not the selected for the project. If you’re really interested in working at the Summer of Code, we encourage you to also submit another proposal to some other project of your choice (it can either be another Mozilla one or to other equally awesome open-source organization). Multiple submissions are fine as long as your other proposals receive similar dedication and are not just something quickly put together to increase your chances to be picked up (which wouldn’t help in the first place among other quality proposals).

Posted by: felipe | April 30, 2012

Using about:cc to fix leaks

Last week in Toronto, the Firefox team had a work week. One of the activities was a session with lightning talks about various aspects of Firefox development. I gave a lightning talk on how to use Olli’s about:cc add-on to find a leak in the front-end code, understand it and fix it. I tried to emphasize the importance of not creating leaks not only for memory use but also for the browser’s responsiveness, and preparing for it was a good exercise as it helped me learn more how to use it myself.

Here is the video for it, and the awesomely-formatted slides and links are here.

As an alternative, Honza created a similar add-on that uses the same underlying API and has a more user-friendly UI. It’s called about:ccdump and you can find how to use it in his blog post.

Shameless plug:
if you liked the subject and are interested in helping: both about:cc and about:ccdemo uses the cycle collection API to get the cycles data and analyze it. It would be great if this API was also used as part of our testing framework to analyze the data after a test run and help prevent new bugs being introduced. If you would like to work on it, this is filed as bug 728294.

Posted by: felipe | February 28, 2012

List of existing memory/performance debugging tools

About:jank, about:ccdump, MemChaser, the profiler… I like to follow the development of all these new tools that we are creating help debug and understand our code behavior better, but it’s getting harder to keep track of all of them, and to remember what is the purpose and location of each. What’s the URL for that tool again?, Is about:jank hosted on AMO?

To make this easier I’ve created a list on MDN with all these add-ons (well, all the ones that I could remember). The purpose of this list is to have a short summary of each tool, a description of what it’s useful for, and a simple explanation on how to use it; plus a link to install and to get more information. There were some other similar lists spread accross MDN and the Wiki, but they were mostly outdated, so the reason I started a new page from stratch is to only have tools that are known to be supported and currently working.

Please add anything that I missed and feel free to improve the description or summaries for anything!

« Newer Posts - Older Posts »

Categories