Presentations and Documents and Research, Oh My! (cross-post)

One of the MSU Capstone team members, Brandon Waterloo, wrote up a nice blog post giving an update on the progress of their work implementing some multitouch gestures for desktop Firefox.

The latter half of the past week, as well as most of this week, consisted (will consist) primarily of working on our project plan document and our presentations. On the 23rd, we’ll be giving team status reports, talking about the status of our machines, our project plan document, etc. These will be short, only about five minutes.

Beginning on the 28th, the various capstone teams will begin presenting their project plans. This is mostly just a brief version of the project plan document. This will be about a fifteen minute presentation. I’m slightly concerned that we can’t stretch our material out to fifteen minutes, because our project is pretty simple to explain–touch gestures for Firefox on Mac OS X. There’s not a whole lot more to say, except to explain the specifics of what we’ll be doing.

Read the rest of the blog post at Brandon’s post, “Presentations and Documents and Research, Oh My!”

Left-to-right: Raymond Heldt (HeldtNotHelt), Brandon Waterloo (we11ington), Bill de Araujo (spartanfire)

Tools & Processes for ensuring software quality at Mozilla

Last week I gave a talk at TechSmith about some of the tools & processes for ensuring software quality at Mozilla.

TechSmith develops multimedia software based around various screen capture uses. Some of their most popular software is Camtasia Studio and Snagit.

Like Mozilla, they use continuous integration, unit tests, manual testing, and code reviews to maintain software quality.

The talk was recorded and I hope to get a copy of the talk to upload here and share with others. In the meantime, I’ve included a link to the slides below:

Please let me know if I made any errors or omissions.

Firefox Performance/Snappy Work Week: Warsaw edition

Last week I was with the “Snappy” team in Warsaw, Poland working out of the Noa Cowork space.

While there I got to meet more people that I have talked with online before and build stronger relationships. I also learnt a lot from Bas Schouten and Benoit Girard as they showed me the tools that they have been working on recently.

Bas works from Holland and is on the Graphics team. Firefox’ tab strip and toolbar area is one of our biggest areas of concern when it comes to snappiness. It is probably the most visible part of the browser that users attribute to responsiveness. Users may blame slow webpages on the website authors, but slow browser chrome will most definitely be blamed on Firefox itself.

Bas wrote a tool that records all of the drawing commands that the graphics system performs. These commands are then saved out to a file and his program can replay them step-by-step. This tool is really great at finding problematic drawing sequences.

In a couple cases, Firefox reaches near completion of drawing the navigation toolbar, and then decides to start the process over. One metric showed there were around 95% redundant drawing commands due to issues like this. While this tool is great at finding these issues, it’s not perfect. There is still a lot of work to do to find the relationship between our CSS, markup, and graphics system to determine which area is causing the issues and how we can fix them.

It should be noted the 95% redundancies seen is partially due to some aspects of the way we are currently using the drawing architecture. It does not mean 95% of performance is wasted. The practical speedup that could be achieved by removing redundancy is estimated to be between 10-20%. Further improvements can be achieved though by optimizing the actual drawing sequences. – Bas Schouten

I spent Monday and Tuesday working with Bas’ tool trying to fix some of the invalidation bugs that we were seeing. After I had one of the patches ready for review, we found that the invalidation issues were the cause of another bug and was only reproducible if the user had enabled an off-by-default preference.  While my bug fix was void, the knowledge gained was very valuable. Tim Taubert was able to work around the root cause of the invalidation issue and fix the browser.newtab.preload implementation to remove the extra invalidations.

I’m really happy to see this tool though, as issues like these could never be discovered without it.

Benoit works from Toronto and is also on the Graphics team. Benoit picked up a side project to implement a native profiler in to Firefox. This profiler is used to find areas of jank within the browser. Getting a profile of the browser is only a click away when the browser becomes unresponsive. These profiles greatly help Firefox developers fix these responsiveness issues.

To use the Gecko Profiler you will need to run a Nightly build of the browser and install the Gecko Profiler add-on. The add-on installs itself in to the Add-On Bar at the bottom of the browser. Pressing Ctrl+Shift+O will show the current profile.

I spent the second part of the week working on fixing one of the issues that the profiler found. The code for highlighting the base domain in Firefox contained some inefficient regular expressions and  I was able to replace them with simple string manipulation. This improvement sped up the function by ~40%.

Overall I think the Snappy work week was really productive. It’s really nice to get people from various teams in the same room for a week since the barrier to communication is much lower. Weeks like these are even more valuable as a way to get to know your coworkers since IRC and Bugzilla aren’t perfect ways to express your thoughts.

Update (24 Sept): I included a clarification from Bas on the 95% redundancy remark.

My presentation at MozCamp EU

The Social API

Two weekends ago I was at MozCamp EU in Warsaw, Poland. Gavin Sharp and I presented on Sunday afternoon, going over Firefox’s upcoming Social API. We showcased its capabilities and answered questions about the roadmap for the feature.

The video of our talk is not online at the moment, but I will update this blog post when the video becomes available.

To demo the Social API, I made a sample social provider that instruments most of the Social API features. The provider is called Ephemeral, and it revolves around short-lived communications.

Ephemeral

The main features of Ephemeral are its chat rooms and its ability to share webpages with the whole network. Up to 15 webpages can be shared among the network at any given time with new messages replacing older ones.

If you are on a webpage that you would like to share with others on Ephemeral, click on the martini glass in the location bar. This button instantly shares the webpage with the social network. Clicking on the now-empty martini glass will display a share panel where you can “unshare” the page. Unsharing will remove all instances of this page from the shared pages in the social network.

This last bit gives a sense of anarchy to the network

To test out my sample social provider perform the following steps:

1) Go to about:config
2) Right-click on a preference and create a New -> String preference with the following values:
2a) name = social.provider.ephemeral
2b) value = {"origin":"https://warm-bayou-4025.herokuapp.com","name":"Ephemeral","workerURL":"https://warm-bayou-4025.herokuapp.com/worker.js","iconURL":"https://warm-bayou-4025.herokuapp.com/favicon.png","sidebarURL":"https://warm-bayou-4025.herokuapp.com/"}
3) Enable the social.active preference
4) Enable the social.enabled preference

Please Help Test

I, and the others working on the Social API, could really use your help in testing this new featureset out. If you’ve got bugs, issues, or feedback about Ephemeral or the Social API, please post them on this Etherpad.

Determining where the bug lies (Ephemeral vs. Social API) can be tricky, so I’ll take care of triaging the responses.

In Summary

The Social API is really cool. It will allow websites to gain tighter integration with the webbrowser without having to write XUL or modify the browser chrome.

If you are interested in making your own social provider, you can reference the Social API documentation on GitHub. Feel free to also follow the source code for my demo provider, although be nice since I only spent two days making it

Status Update 2 of Reader Mode for desktop Firefox

I’d like to start this status update off by introducing the team that is working on the project.

The students working on the project, from left to right, are Matt Vorce, Michael Anderson, Chelsea Carr, and Kevin Woodward.

This past week the students put together a roadmap of the semester, outlining their ideal progress and pace for the project.

The roadmap has the project nearing completion before Thanksgiving break, which is around November 22nd.

All four students now have their “first bugs” assigned to them and I believe that all of their bugs have now been fixed and have had their code pushed to mozilla-central.

The meta bug for tracking the work that the students will be doing is bug 558882, “Ship Readability in the browser.” I am planning on giving more bug-filing responsibility to the students this semester.

Here’s the minutes from today’s meeting that Matt typed up:

Things to do going forward:

Get something up and running ASAP. Do not focus on the HTML and CSS for the time being.

Ignore Sync at first until we have the reader mode working the way we want it.

After coming up with a sketch of how the user experience would work for reader mode try to run it by the User Experience team.

Create a user experience interaction diagram

Order of priorities:

Reader Mode > Reading List > Sync > Preferences

Task this week is to break up getting the basic reader mode done. Examples of how we might break it up:

One person get the button in the toolbar and make it create a basic popup

One person work on checking whether a webpage is compatible with the reader mode

One person work on getting a page to display correctly in the reader mode