I’m going to start the year off with a blog post, mostly to procrastinate on replying to the many e-mails that my very productive colleagues have sent my way 🙂

2017 was quite a year beyond the socio-economic, geo-political, and bizarre. I, and many of my colleagues did what we could: find solace in work. I’ve often found that in uncertain times, making forward progress on difficult technical projects provides just enough incentive to continue for a bit longer. With the successful release of Firefox 57, I’m again optimistic about the future for the technical work. The Firefox Layout Engine team has a lot to be proud of in the 57 version. The winning combination was shipping big-ticket investments, and grinding down on many very difficult bugs. Plan “A” all the way!

Of course, it’s easy to see this in retrospect. I recall many late nights wondering “is this even going to work?” My friend and former colleague Robert O’Callahan recently revealed that he had similar doubts from before my time on the project. I wonder how much of that is inherent in the work. Is the Mozilla mission also the same narrative that fills me and other leaders with the sense that we’re always in rescue mode? Is that a sustainable lifestyle? In any case, it does feel like we’ve turned a corner.

For the first time in a long time, I feel like the wind’s at our backs and about to go into 2018 with that momentum. It would be hubris on my part to say that we’ve figured it all out. 2018’s uncertainties (e.g, Spectre/Meltdown) promise more late nights ahead. We’ve got lots of things in flight, and more ideas to investigate. We’ll need to make changes to deal with it all, but that’s par for the coming year’s course.

Happy New Year!

All of Mozilla is currently in San Francisco for the semi-annual All-Hands event. The Web Platform Layout team also meets here to discuss current work and future projects. Our team is responsible for the following browser rendering operations:

1. Compute Style
2. Size
3. Position
4. Animate
5. Paint

…in 2D, 3D, and Virtual Reality.

Because we typically operate 7 days a week, 24 hours a day across the globe, it’s a rare opportunity to meet with everyone to share what we’ve been working on, and where we’re going next. We took turns doing Lightning Talks with each team member taking 2 to 5 minutes to share:

• A brief introduction.
• What you worked on since the last All-Hands.
• What you plan to work on next.
• What you want to learn while you’re here.

This was a “behind the scenes” chat about the guts of the Layout Engine, as illustrated in this image:

I’ve been thinking about the internals of our Web Layout Engines and how it’s a lot like the internal movement of a mechanical wristwatch. I shared the following story about the Swiss watch industry before our meeting started. I think the similarities with the web browser business are interesting.

Swiss watches are often regarded as the best of the best in haute horology. The long history of handcrafted manufacturing and very successful marketing around a watch’s provenance have made for a multi-billion dollar industry.

The most complex and expensive part of a wristwatch is its movement: the machine that rotates the watch hands and other complications. In that sense, a watch movement is not unlike a web browser’s layout engine, which controls the display of a browser’s content.

Within the wristwatch industry, there’s a debate about the differences between in-house movements (made by the watch vendor) and outsourced movements. ETA is a relatively obscure Swiss company that manufactures watch movements for other watch brands. There’s a long list of watch vendors that source their movements from ETA. This makes for what seems to be a great business plan: outsource the most expensive components, design the external case/dial appearance, add effective marketing, and you’re in the high-margin Swiss Watch business.

Why bother building your own watch movements, when you can use a cheaper one off the shelf? Why bother building your own layout engine, when you can use one of several “free” alternatives?

Here’s one very good reason why: In 2003 the Swiss Government launched an investigation into ETA after they announced that they would stop supplying watch movements to other companies after being acquired by The Swatch Group. The same Swatch Group that sells low-cost plastic watches at shopping malls around the world also owns several luxury watch brands. What do you do when the giant corporation that builds your watch movements decides to stop supplying? What happens when the giant corporation that builds your layout engine decides to unfairly favor its own products?

The level of skill and effort required to design and build a watch movement is an order of magnitude beyond what’s required for the outer components. There are a number of companies that still manufacture in-house movements: Patek Philippe, Rolex, and Seiko are 3 examples. I personally wear a Seiko that I bought for less than $100. My preference for in-house movements is not about price, luxury, or exclusivity. I believe there’s great value in the independent creativity and craftsmanship inherent in building the whole widget. I also love pushing the state of the art and not being limited by what others decide that we can offer. Food for thought as we work on the layout engine this week.

It’s been way too long since I posted on this blog. It seems I’ve fallen into the 140-character vortex like so many bloggers. I will endeavor to work on that in 2017.

I’m often asked “What’s up with this bug?” or some variation. This is often the case when a reported software defect is stuck in a status other than “fixed.” I then have to get in there, figure out what’s stuck, and somehow get it unstuck.

I’m almost never the first responder. By the time I’m called in, people smarter than me have already been looking into the problem, and my job is to light a fire under the bug. That is, there may already be enough information known to get a fix, it just needs the right spark.

Sometimes, that job requires that I find an appropriate person to assign the bug to. I try to add some new value (other than point a finger) when asked to light these fires under bugs. In some cases, I hack together a feeble fix, then a “real engineer” comes in and fixes it up for production. In rare cases, my code gets checked into the trunk.

I feel like this is one of the most important jobs for the Engineering Manager, but I haven’t read much material on the subject. It’s not a task where I get to display superior technical acumen, or simply throw managerial weight around. It requires patience, thought, and a bit of luck–much like lighting a campfire in the rain.

I’m often assigned Firefox Rendering bugs in bugzilla. By the time a bug gets assigned to me, the reporter had usually exhausted other options and assumed (correctly) that I’m ultimately responsible for fixing Firefox rendering bugs. Of course, I often have to reassign most bugs to more capable individuals.

Some of the hardest bugs to assign are the ones reported by our own Gaia team: the team responsible for building the user experience in Firefox OS. The Gaia engineers take CSS and JavaScript and build powerful mobile apps like the phone dialer and SMS client. When they report bugs, it’s often found within lots of CSS and JS code. I wanted to learn how to effectively reduce the time it takes to resolve rendering issues reported by the Gaia team. It takes a long time to go from a Gaia bug like “scrolling in the gallery app is slow” to find the underlying Gecko bug, for example “rounding issue creates an invalidation rectangle that is too large.”

To do that, I became a Gaia developer for a few days at our Paris office. I reasoned that if I could learn how they work, then I can help my team boil down issues faster and become more responsive to their needs. We already recognize the value of having expert web application developers on staff, but we could do a better job with a better understanding of how they work. With that in mind, I spent the week without any C++ code to look at, and dived into the world of mobile web app development.

I wrote down the steps I took to set up a FirefoxOS build and test environment in an earlier post This time, I’ll list a few of the tips and tricks I learned while I was working with the Gaia developers.

The first and most important tip: You will brick the phone when working on the OS. In fact, you’re probably not trying hard enough if you don’t brick it 🙂 Fastboot lets you connect ADB to the phone when it becomes unresponsive to flash the device with a known good system (like the base image.) Learn how to manually force fastboot on your phone.

Julien showed me how to maintain a Gaia developer profile on your desktop development environment. This set of commands will configure your B2G build to produce the desktop B2G runtime that’s a bit easier to debug than a device build:

# change value of the FIREFOX to point to the full path to the B2G desktop build
 export FIREFOX=/Volumes/firefoxos/B2G/build/dist/B2G.app/Contents/MacOS/b2g
 export PROFILE_FOLDER=gaia-profile DEBUG=1 DESKTOP=0
 make

With a Gaia developer profile, you can switch between B2G desktop and a regular Firefox browser build for testing:

export FIREFOX=/full/path/to/desktop/browser
 $FIREFOX -profile gaia-profile --no-remote app://sms.gaiamobile.org

The Gaia profile lets you use URL’s like app://sms.gaiamobile.org to run the Gaia apps on the desktop browser. This trick alone was a huge time saver! Try it with other URL’s like app://communications.gaiamobile.org

For a first Gaia development project, I picked up the implementation of the new card view for gaia that is based on an asynchronous panning and zooming (APZC.) Etienne did the initial proof-of-concept and my goal is to rebase/finish/polish it and add some CSS Scroll Snapping features. My initial tests for this feature are very promising. CSS Scroll Snapping is much more responsive than the previous JavaScript-based implementation. I’m still working out some bugs but hope to land my first Gaia pull request soon.

I’ve already been able to apply what I’ve learned to triage bugs like this one. The bug started out described as a problem with how we launch GMail on B2G in Arabic language. Based on the testing tricks I learned from Gaia team, I was able to distill it to a root cause with scrollbar rendering on right-to-left (RTL) languages. I added a simplified test case to the bug that should greatly reduce debugging time, and assigned it to one of our RTL experts. That’s quite a bit better than assigning tough bugs to random developers with the entire OS as the test case!

Thanks to Julien and Ettiene for helping me get up to speed. I highly recommend that any Gecko engineer spend a few days as a Gaia hacker. I’m humbled by the ingenuity these developers have for building the entire OS user experience with only the capabilities offered by the Web. We could all learn a lot in the trenches with these hackers!

Regular readers of my blog know that I also worked on the Macromedia Flash Professional authoring tool and the Adobe Flash Player for many years. I learned a great deal about the design of ubiquitous platforms, and the limitations of single-vendor implementations. At a recent meeting with the W3C SVG working group, I shared some of my thoughts on how Flash was able to reach critical mass across the Web, and how SVG can leverage those lessons for the future.

Basically, it boils down to 3 principles:
1. Flash offered expressive design-fidelity across all user agents.
2. Flash authoring was superior to SVG authoring tools for producing content that adheres to principle # 1.
3. Most Flash content is self-contained and atomic in a packaged file format that helped preserve design-fidelity in # 1.

I shared some feedback regarding what I hear from Firefox users about SVG. I also shared what I never hear from Firefox users: “We need more SVG features.”

As the working group ponders new SVG specifications for review, the main gripe I hear from users is the lack of interoperability for the current feature set. That is, I don’t get requests for a new DOM or fancy gradient meshes, I get bugs about basic rendering differences across browsers. As a result, I’ve directed our SVG investment towards these paper cuts that make authors distrust SVG for complex designs. I can see why it’s more tempting to focus on new feature specifications, but adoption is hampered by the legacy of interoperability (or lack thereof.) I’d like to see the group organize around fixing these bugs across all browsers in a coordinated fashion, eg. in a hackathon or bug bash at a future multi-browser face-to-face meeting.

I also talked about how SVG could be a very expressive authoring source format for a modern implementation that is more focused on pixel-fidelity. Unfortunately, I didn’t get a lot of support for that idea from other browser vendors, as the desire to compete for the best implementation seemed to outweigh the benefits of dependable runtime characteristics. I’m really surprised that SVG hasn’t stepped in to replace Flash for more use cases, and I’m quite certain that the 3 principles I mentioned above are the reason why. I do hope that authoring tool vendors step in and help drive the state of the art here. It’s one thing for browser vendors to offer competing implementations, but the lack of strong authoring systems makes it hard to define what it means to be correct.

I spoke with a few people about how the packaged SWF format was an advantage for Flash because it was easy to have this content move across the internet in a viral fashion without losing any of the assets. Flash games, for example, are commonly hosted on multiple servers (often unknown to the original publisher) and still retain all the graphics and logic within the SWF file. The W3C application package proposal is something we could implement as a format that lets HTML/SVG content traverse networks intact. It’s not hard for such HTML/SVG applications to be made up of hundreds of individual assets that are easy to lose track of. Having a packaged format with clear semantics and security rules (eg. iframe in a zip) could be a really good feature for the modern web.

What else are we missing for SVG to gain critical mass? Post a reply below or find me on twitter!

I occasionally accept invitations to speak at conferences and events. Here’s the video from my recent talk at The Graphical Web in Winchester, England. I discuss how and why I now work on Web Platform Rendering, and how disruptive innovations are enabled by seemingly mundane key technologies that bridge gaps for developers and audiences.