<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.

Australis-Styled Widgets Presentation

I’ve been pretty quiet this semester about the work that a team of students have been focused on. However, don’t let my quietness be a representation of how hard they have worked.

We’re now reaching the end of the semester and the students have put together a video of their work throughout the semester. The students were tasked with creating three add-ons for the upcoming Australis version of Firefox.

The goal of the project was to get feedback on the new Australis add-on APIs before it became too late to make significant changes. Through the process some bugs were filed, but none that caused us to have to go back and rethink our initial direction.

The three add-ons that the students were asked to create were a weather add-on, music add-on, and Bugzilla add-on. Please watch the video below to get an overview of their capabilities.

You can view the source code for the Weather widget and the Bugzilla widget online.

Student project: Australis-styled widgets

A couple weeks back, Gijs Kruitbosch and I began mentoring a group of students on a new student project focused on building some new Australis-styled widgets.

The team is comprised of students from Michigan State University’s Computer Science program. Pictured from left to right are Dan Poggi, Eric Proper, Eric Slenk, and Dave Thorpe.

The goal of the project will be to create four independent widgets using the Add-on SDK and new Australis widget API:

1. A weather widget that can show the weather for a selected location as well as up to 5-7 additional locations. This will need to use a public and free weather API.
2. A music playing widget that will play music located on the user’s local machine. The user can select a folder on their machine and the widget will play any media files that it can find within that folder or in that folder’s children. We may need to limit the recursive depth to 2 folders.
3. A Bugzilla widget that will show the assigned bugs, review requests, etc. This will be based on Heather Arthur‘s excellent Bugzilla Todos dashboard.
4. A Spartan Scoreboard widget that will show the date, opponent, and location of the next MSU sporting event, as well as the score of the previous game. It should also include a link to get more information.

Eric Proper, Eric Slenk, and David Thorpe have begun blogging about their progress. You can follow along and get more details on their respective blogs. Eric Proper has an amazing amount of detail already on his blog. I’m looking forward to seeing the blogs from Dan Poggi and Dave Thorpe.

We will be meeting weekly at 9:00am Eastern time on Thursdays throughout the Fall semester.