18 January, 2013 § Leave a Comment
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!”
11 December, 2012 § 2 Comments
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.
22 September, 2012 § 3 Comments
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.
17 September, 2012 § Leave a Comment
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