The Capstone Hackweekend

This past weekend Mike Conley and I visited the Capstone team to work one-on-one with the students, teach topics, and share the history of Mozilla.

The current capstone project is a continuation from last semesters project. The students are working on converting Firefox’s localization implementation from DTD/properties files to Fluent. Fluent brings with it many new capabilities, such as platform-dependent strings, custom formatters, asynchronous applying of translation, and more.

Last semester’s capstone group migrating parts of Firefox and wrote migration scripts. They also attempted to migrate startup strings and profile the performance implications.

This semester the students are continuing to migrate more parts of Firefox, while also working on our Fluent tools and researching using a faster parser.

Topics for the weekend

We met the students bright and early Saturday morning at 9am. The first topics that we covered were the page lifecycle as it applies to Fluent translation and comparisons to how DTD and .properties files have their strings applied. We also covered Fluent best practices (limiting formatValues where possible, for example).

Through a long day of hacking and learning about how code is written, tested, and shipped at Mozilla, the students wrote patches for the following bugs:

• Migrate about:rights to Fluent
• Convert resetProfile.dtd to Fluent
• Convert unknownContentType.dtd to Fluent
• Migrate pageInfo.dtd to Fluent
• Convert migration.dtd to Fluent
• Migrate about:tabcrashed to Fluent
• Capstone: convert about:privatebrowsing using gandalf’s conversion script

On Saturday night, we hosted our first-ever “Mozilla movie-night” on campus, showing the 2000 documentary “Code Rush.” The documentary covers the open-sourcing of Netscape and the birth of Mozilla. It was pretty impressive to see over 20 college students show up to the Engineering Building at 8:30pm on a Saturday night. Mike and I also did a Q&A with the students before and after the movie about working in open source software, applying for jobs, and more.

Sunday morning we were back in the computer lab at 9am again for a half-day of hacking. We spent the first hour of the day teaching how to know if a test failure on tryserver is an intermittent failure related to the current patch or a pre-existing and known issue. This is very useful as the students have been pushing their patches to tryserver more often this semester than in previous groups.

This was our sixth time that we’ve hosted a hack weekend with the Capstone team (different team each semester). We schedule these to occur within the first few weeks of the start of the semester to help bootstrap the students on their project. It’s been a very valuable use of all of our time, as it helps the students get some face-time with their mentors, and the mentors get a better grasp of some of the challenges that the students are facing.

<select> dropdown update 3

First, let me say that the students working on this project have done a great job. Secondly, let me say that I’ve not done a great job blogging about their work. I will try to make up for it in this post.

Since the previous post a lot has happened: we had our hack-weekend at MSU, the students implemented the features we asked them to work on, a bonus feature got implemented, the students made a video about their project, and then they presented their project as part of their end-of-the-semester Design Day exhibition.

I’ll go through each item of the above list:

Our “hack-weekend” at MSU

On about the fifth weekend of the project, Mike and I visited the MSU campus to work with the students and familiarize them with the project and the Mozilla codebase. We covered all aspects of the tools: Bugzilla, Mercurial, Reviewboard, and the Browser Toolbox. We gave short lessons on interprocess communication, low-level CSS styling implementation, and distributed version control systems.

What worked

• The location and facilities were great. We had solid connections to the internet, a comfortable room, and no hassles.
• The team was very astute and asked many questions as we were going along.
• Bugzilla and Reviewboard seemed to get understood well.
• There was tons of paired programming and hacking on the project, and great career discussions as well.
• The students wrote some amazing automated tests for searching in the dropdown. It is great to give students a real-world project that includes so many parts of good software development (automated tests, code reviews, version control, paired programming, code linting, and fixing regression bugs).

What didn’t work

• I think we should have done the hack weekend a little sooner in the semester. The sooner the better, as we can try to get ahead of any tooling issues, ambiguities in the spec, and technologies that should be covered. For example, at the beginning of the semester I asked that each student complete a set of online tutorials. After going through the lessons I got the feeling that there was still some room to grow and understand more about the programming languages we were using.
• Mercurial seemed very hard to get a grasp of. Some of this may have been due to the paired programming where the students were sharing patches, and the rest is probably due to Mike and I not having a solid plan at the beginning of the semester as to how the students can share and update each others patches. We should probably set up a non-publishing user repo that all students will have access to and push to as they are working on the project.
• The students used Mercurial’s bookmark-based development model, and I still use the Mercurial Queues method. This meant that I wasn’t much help when the students got stuck. I’m switching my development model to bookmark-based development before the next semester starts.
• Two of the groups of students were paired up. This seemed to work OK in the beginning, but soon it seemed that the students weren’t doing a good job of switching off. I think we will try to do less pairing at the beginning, and maybe introduce pairing towards the end once the students have gotten a grasp of the tools, codebase, and project requirements.

The work that got completed

Mark landed the styling changes for the dropdown. The dropdowns now have more padding around each item, show a grey background for theheaders, and have correct hover styling. All of this work was for Windows-only, as Linux and OSX looked fine already.

Mark also landed a patch to increase the padding of items when the dropdown is opened on a touch-enabled device. I landed a small follow-up to only show the increased padding when a touch-event was used to open the dropdown.

Jared landed an OSX-only patch to open the dropdown vertically centered on the selected item. This brings us in parity with Safari on OSX. We may possibly do the same for Windows now that Edge is showing the behavior there, though it is not planned for anytime soon. This feature was a bonus, as we didn’t expect the students to have the time to get to it when the project was started.

The work that is near completion

Tyler and Jared worked on implementing search within the dropdown. The search box only shows up if there are over 40 items in the list, and it will provide live filtering of the menuitems. There are some cool automated tests that Tyler wrote that verify the functionality works. These tests will be easy to expand upon in the future if any regressions are found or the feature is to get expanded. This is pretty close to landing and will hopefully land this week or next, depending on how quick the students are at responding to the review feedback.

Michael and Fred worked on getting single-process Firefox to use the multi-process Firefox implementation of the <select> dropdowns. This work was pretty low-level and required the students to set up a debugger on a separate machine and use remoting to control the browser (to avoid issues with focus changing). This is getting pretty close to landing, but will need a separate bug fixed first before the students can push further on it. I hope we can get it to land in the next couple weeks.

Project video

As part of the course requirements, the students made a video to showcase their work. Watch below, it’s pretty good (and funny too!)

Sorry for not blogging about their project more often. The students did a great job on the project and we hope to see them stay active in the Mozilla community going forward.

<select> dropdown update 2

Mike and I met with the “select dropdown” team today and discussed where they’re at and the work that they can focus on for the next week. We are discussing a possible “hack-weekend” October 1st and 2nd at Michigan State.

Freddy got XCode up and running and can debug processes at the single-process/multi-process fork. Jared and Miguel are having issues getting their debugger to work. Freddy will be helping Jared and Miguel with their setup to compare what is different, with the fallback being Jared and Miguel using LLDB as their debugger.

In the past week, the team has also been spending time working on presentations and project plans.

For C++ code, their initial plan was to fake the single-process to run through the multi-process code path by removing the checks for if the code is running in a content process and if a special e10s desktop preference is enabled.

As a quick technical dive: When a select dropdown is clicked, we determine that we’re running in a content process, and we fire an event (“mozshowdropdown”). A content script running in the content process listens for the “mozshowdropdown” event and opens the popup.

The plan to fake the single-process to run through the multi-process won’t work though, because the content script mentioned above won’t be loaded and thus there won’t be an event listener. The content-script is only loaded right now through the remote-browser.xml binding. The content-script would have to be loaded through the non-remote-browser binding (browser.xml) as well as the various message listeners and event listeners.

While working on this, it would be a good idea to move the code from select-child.js to browser-content.js, since we don’t really need a separate file for select items and browser-content.js is loaded in single-process Firefox.

As for styling changes, the students were able to use the Browser Toolbox to change web content through forms.css and see how things like input textboxes could get different default colors. To change the styling of a select dropdown, the students will play around in browser.css to tweak the styling. In the end they’ll want to make sure that the styling exists under the /themes directory, and likely within /themes/shared/.

One of the students asked if we had ideas about specific algorithms or design-patterns that the search-within-the-dropdown implementation should use. We pointed them at the Browser Console’s filtering ability and asked that the students follow the implementation there.

That wraps up our notes from this week’s meeting. We’ll be meeting regularly for the next 10-ish weeks as the students make progress on their work.

Improving <select> dropdowns

Last week marked the beginning of a new 12-week period of mentorship for myself. I’ll be working Mike Conley to share mentorship duties as we mentor a group of five Michigan State University students. The students are all seniors in the Computer Science program.

The MSU Capstone is a program that pairs industry companies with small student groups to give students access to real-world software development and the software development life cycle.

This semester, the five students will be working on improving the visual design of the <select> dropdown. The project has three main components:

1. The <select> dropdown has two separate implementations: one for single-process Firefox (going away soon), and another for multi-process (e10s) Firefox (the new hotness). The old implementation should be removed, and single-process Firefox should use the implementation that was added as part of the e10s project.
2. The default look and feel of the <select> dropdown is pretty packed. We want to give more space to the items in the popup to allow for improved readability, as well as making it look more “modern”.
3. <select> dropdowns have pretty bad usability when the number of items gets very large. They’re also pretty hard to use on touch-screens. The dropdowns should have the ability to filter items and should have more padding when opened via a touch event. The increased padding is intended to make it easier to tap on the desired option as well as to make the options easier to read when they may have a finger hovering over them.

(left to right) Jared Beach, Fred Luo, Mark Golbeck,
Miguel Wright, Tyler Maklebust

Since the students were assigned to the project last week, they now have local builds up and running as well as Bugzilla accounts. We’ve been active on IRC and will have weekly check-in meetings over Vidyo.

I’ll have more to share in the coming weeks as the students begin ramping up on their work.

New in Firefox Nightly: In-content Preferences

I’m happy to announce that starting today, the new in-content preferences are enabled by default in Firefox Nightly.

This project was started by a group of students at Michigan State University and was mentored by Blair McBride and myself. Since its start, it has continued to get a ton of attention from contributors world-wide.

This is a list of people who have contributed patches to the in-content preferences as of this posting:

• Ally Naaktgeboren
• Andres Hernandez
• Andrew Hurle
• Benjamin Peterson
• Benjamin Smedberg
• Brendan Dahl
• Brian R. Bondy
• Brian Smith
• Carsten “Tomcat” Book
• Chris Mahoney
• Chris Peterson
• Christian Ascheberg
• Christian Sonne
• Devan Sayles
• Dão Gottwald
• Ed Morley
• Ehsan Akhgari
• Florian Quèze
• Gervase Markham
• Gijs Kruitbosch
• Gregory Szorc
• Honza Bambas
• Jan de Mooij
• Jan Varga
• Jared Wein
• Javi Rueda
• Jeff Walden
• John Schoenick
• Jon Rietveld
• Jonathan Mayer

• Josh Matthews
• JosiahOne
• Kyle Machulis
• Mahdi Dibaiee
• Manish Goregaokar
• Manish Goregaokar
• Mark Hammond
• Martin Stransky
• Matthew Noorenberghe
• Michael Harrison
• Mike Connor
• Mike Hommey
• Ms2ger
• Nicholas Nethercote
• Nick Alexander
• Owen Carpenter
• Paolo Amadini
• Phil Ringnalda
• Richard Marti
• Richard Newman
• rsx11m
• Ryan VanderMeulen
• Sebastian Hengst
• Sid Stamm
• Ted Mielczarek
• Theo Chevalier
• Tim Taubert
• Yosy
• Zuhao (Joe) Chen

There is still a lot of work to be done before shipping the new in-content preferences out to people on the release builds of Firefox. That also means that this long list of contributors doesn’t have to stay at 59 people, it can keep growing 🙂

We have a list of bugs that we need to fix before we can call version 1 of this project complete. The easiest way for someone new to help out is to download Firefox Nightly and help test that the new preferences work just as well as the old preferences. If you find an issue and see that it hasn’t already been reported, please file a new bug in Bugzilla and leave a comment on this blog post with a link to the bug that you filed.