Category Archives: PlanetFirefox

Mozilla office history

If you don’t live in the San Francisco Bay area, you may not be aware that the culmination of a major infrastructure project is underway this holiday weekend. The Bay Bridge, one of 5 major Bay-area bridges, is in the middle of a 5 1/2 day closure as it’s transitioned over to its replacement. (The other 4 major bridges, in case you’re wondering, are the
Richmond–San Rafael Bridge, the San Mateo Bridge, the Dumbarton Bridge, aaaand… hmmm… oh, right, the Golden Gate bridge)

The Bay Bridge was originally built in the 1930s, and after the Loma Prieta earthquake in 1989 it became clear it needed to be replaced. One of the flashbulb memories many people have of the quake — in addition to it interrupting the ’89 World Series and the collapse of the double-decker Cypress Street Viaduct — is the failure of a span on the Bay Bridge, with cars driving over it. Since then, the western half of the Bay Bridge has been retrofitted to be earthquake-safe, but the eastern span of the bridge has taken longer to completely replace. This weekend’s work is to transition the connection points, so that tomorrow people will be driving over a completely new bridge that’s been 11 years and $6.4 billion in the making!

(I’m getting to the part where Mozilla ties into this.)

Last Friday @BurritoJustice tweeted a link to a slideshow that dove into the engineering history of the Bay Bridge, complete with photos taken during the construction.

It’s some fantastic engineering porn, and I spent my lunch reading through all of it. I happened to notice that the building in the background of one of the photos looked familiar…

Mozilla’s San Francisco office, in the historic Hills Brothers Coffee building at 2 Harrison Street, is literally next-door to where the western span of the Bay Bridge lands in S.F. It makes for some really great views of the bridge from our top-floor patio:

As well as a first-row seat beneath the giant “HILLS BROS COFFEE” sign atop the building.

It’s this sign that made it easy to spot our building in the engineering history slideshow. The building was constructed in 1926, and the Bay Bridge wasn’t built until 1933-1936, so I was curious to see if the sign was visible in other contemporaneous photos. I started digging though some online resources, and got lucky right away by finding a highres version of that picture at the Library Of Congress:

I skimmed through the other 415 photos in this collection and another 1160 from UC Berkeley (So You Don’t Have To™), and found some other nice shots with the Hills Coffee sign peeking out from the background:

So there you have it. Pics of the Mozilla San Francisco office from both ends of an 80 year span of history.

On Firefox’s Password Manager

It’s been a while since I last blogged about Firefox’s password manager. No big deal, it really hasn’t fundamentally changed since since I rewrote it 6 years ago for Firefox 3.0. Well, ok, the storage backend did switch to SQLite, but that’s mostly invisible to users. There’s a noteworthy change coming soon (see next post!), but I figured that would be easier to explain if I first talked about how things currently work. Which I’ve been meaning to do for a long time, ahem.

The first thing you should know is that there is no standard or specification for how login pages work! The browser isn’t involved with the login process, other than to do generic things like loading pages and running javascript. So we basically have to guess about what’s going on in order to fill or save a username/password, and sometimes sites can do things that break this guesswork. I’m actually surprised I don’t get questions about this more often.

So let’s talk about how two of the main functions work — filling in known logins, and saving new logins.

Filling in a known login

The overall process for filling in an existing stored login is simple and brutish.

  1. Use the chrome docloader service and nsIWebProgress to learn when we start loading a new page.
  2. Add a DOMContentLoaded event listener to learn when that page has mostly loaded.
  3. When that event fires…
    1. Check to see if there are any logins stored for this site. If not, we’re done.
    2. Loop through each form element on the page…
      1. Is there an <input type=password> in the form? If not, skip form.
      2. Check to see if any known logins match the particular conditions of this form. If not, skip form.
      3. Check to see if various other conditions prevent us from using the login in this form.
      4. Fill in the username and/or password. Great success!

Phew! But it’s the details of looking at a form where things get complex.

To start with, where do the username and password go? The password is fairly obvious, because we can look for the password-specific input type. (What if there’s more than one? Then we ignore everything after the first.) There’s no unique “username” type, instead we just look for the first regular input field before the password field. At least, that was before HTML5 added more input types. Now we also allow types that could be plausibly be usernames, like <input type=email> (but not types like <input type=color>). Note that this all relies on the order of fields in the DOM — we can’t detect cases where a username is intended to go after the password (thankfully I’ve never seen anyone do this), or cases where other text inputs are inserted between the actual username field and the password (perhaps with a table or CSS to adjust visual ordering).

And then there’s the quirks of the fields themselves. If your username is “alice”, what should happen if the username field already has “bob” filled in? (We don’t change it or fill the password.) Or, more common and depressing, what if the username field already contains “Enter your sign in name here”? In Mongolian? (We treat it like “bob”.) What if the page has <input maxlength=8> but your username is “billvonweiterheimerschmidt”? (We avoid filling anything the user couldn’t have typed.)

And then there’s the quirks of the saved logins. What if the username field already has “ALICE” instead of “alice”? (We ignore case when filling, it’s a little trickier when saving.) Is there a difference between <input name=user> and <input name=login>? (Nope, we stopped using the fieldname in Firefox 3 because it was being used inconsistently, even within a site.) What about a site has both a username+password _and_ a separate password-like PIN? (Surprisingly, we were able to make that work! Depending on the presence of a username field, we prefer one login or the other.)

And then. And then and then and then. Like I said, there’s no spec, and sometimes a site’s usage can break the guesses we make.

Saving a new/changed login

In comparison, the process for saving a login is simpler.

  1. Watch for any form submissions (via a chrome earlyformsubmit observer)
  2. Given a form submission, is there a password field in it? If not, we’re done.
  3. Determine the username and password from the form, and compare with existing logins…
    • If username is new, ask if user wants to save this new login
    • If username exists but the password is different, ask if user wants to change the saved password
    • If username and password are already saved, there’s nothing else to do.

Of course, there are still a number of complicating details!

This whole process is initiated by a form submission. If a site doesn’t actually submit a form (via form.submit() or <button type=submit>), but just runs some JavaScript to process the login, the password manager won’t see it. And thus can’t offer to save a new/changed login for the user. (Note that this is easy for a site to work around — do your work in the form’s onsubmit, but return |false| to cancel the submission).

Oh, and there’s still the same question as before — how to determine which fields are the username and password? We reuse the same algorithm as when filling a page, for consistency. But there are a few wrinkles. The form might be changing a password, so there could be up to 3 relevant password fields (for the cases of: just a new password, old and new passwords, and old + new + confirm.). And the password fields could be in any order! (Surprisingly, again, this works.) The most common problem I’ve seen is an account signup page with other form fields between the username and password, such as “choose a user name, enter your shipping address, set a password”. The password manager will guess wrong and think your zipcode is your username.

Oh, and somewhere in all this I should mention how differences in URLs can prevent filling in a login (or result in saving a seemingly-duplicate login). Clearly and logins should be separate. But we also match on protocol, so that a login will not be filled in on And what about and or (We treat them separately.) What about and (Also separate.) What you might not realize is that we also use the form’s action URL (i.e., where the form is submitted to), ever since bug 360493. While this prevented sending your password to, it also breaks things when a site uses slightly different URLs in various login pages, or later changes where their login forms submit to.

Oh, bother.

All the gory details

This is one of the benefits of being Open Source. If you want to see alllll the gory details of how the Firefox password manager works, you can look at the source code. See In particular, LoginManagerContent.jsm contains the code implementing the stuff discussed in this post, with the main entry points being onContentLoaded() and onFormSubmit().

Finally (!), I’ll mention that the Firefox password manager has some built in logging to help with debugging problems. If you find it not working in some particular case, you can enable the logging and it will often make the problem clear — or at least clearer to a developer when you file a bug!

Unicorns and Mozilla

Let’s file this under “reasons I love working at Mozilla”. Because, well, that’s true and I can’t think of a better place for it!

Months ago (months!), I ran across an amazing, amazing thing for “Unicorn Poop Cookies”. I’ve had this tab open in my browser since then, and it was time to close it out. So I made some cookies. Oh, yes. And who better to share them with than my awesome coworkers?!

Here’s the recipe I used…

  • 1 cup butter
  • 0.75 cup sugar
  • 1 egg
  • 0.5 teaspoon vanilla extract
  • 0.25 teaspoon lemon extract
  • 2.5 cups flour (bleached — I know — to show color better)
  • 1 teaspoon baking powder
  • 0.25 teaspoon salt
  1. Cream butter and sugar. Add liquids, mix well. Slowly combine in remaining dry ingredients.
  2. Let dough chill. Then divide into portions, add coloring (use gel food coloring for bright colors)
  3. Chill again. Form dough into ropes. Splice in various colors, twist. Spiral into cookie-sized portions. Chill yet again.
  4. Make an egg wash (for shininess and to adhere toppings) with 1 egg + splash of water. Brush on. Sprinkle with decorations. “Disco Dust” is great for that added special sparkle.
  5. Bake at 375°F for no more than 8 minutes. Watch carefully, you want the dough to _just_ set, not become brown and crispy. These will be soft, almost underbaked, cookies about the consistency of PlayDoh.
  6. Once cooled, feed everything to a unicorn and wait for nature to Do Its Magic™.
  7. Serve with assortment of marshmallows other omgfluffy things. Such as more unicorns.

TBH, I’ll probably do it differently next time. I think the cookies turned out fine, but I’d rather use almond flavoring instead of lemon. The lemon extract I used gave a nice subtle(?) “tang” upfront, but also gave a distinct lemon aftertaste that lingered a bit too long. I may also be slightly biased for anything almond-flavored. Hmm, maybe an almond paste center would be interesting.

Special thanks to Jonathan Wilde for letting me borrow his Unicorn for this process! 😀

Boom goes the dynamite

This weekend bug 758812 landed on mozilla-central. So begins a long, slow process of splitting up browser.js into smaller pieces.

“What’s the deal with browser.js, anyway?”

It’s big. Too damn big. For those unfamiliar with it, browser.js basically contains a bunch of the code for driving the UI in a Firefox window. Anything you click or see changing as you browse probably involves this code. A browser needs to do a surprising amount of stuff to work, and over time browser.js has become an eclectic collection of code. About 13K lines of code, in fact. That’s a lot, and leads to a number of problems… It’s a daunting behemoth for those new to the Mozilla code base. It’s haphazardly organized (at best), so it’s hard to find things unless you already know what you’re looking for. And looking at Mercurial’s history for the whole file doesn’t really give you a clear picture of how specific pieces evolve.

“So what are you going to do about it, punk?”

Break it up! The first step landed, which is just spinning out a few big chunks of related code into #included files (about 2K lines). As time goes on (and we see how changes work out), we’ll likely spin out even more. Some of these pieces may also end up evolving into JSMs, which has modest benefits for improving memory usage and startup time. We might even be able to share some of this code across products (Firefox, Fennec, B2G).

“And the bad news?”

Well, there really isn’t any. If you’re a Firefox user, you won’t see anything change. If you’re an add-on developer, you’re unlikely to be affected by these changes. The cleaving of browser.js is currently just a source-tree change with #includes, so the resulting browser.js that ships in Firefox is mostly the same. Future changes to move code into JSMs will have some impact, but we’ll try to keep change small and approachable. Really, it’s only Firefox front-end developers who are likely to notice the changes, patches to certain code in browser.js may now need to patch code in browser-foo.js instead.

“I’m not seeing any cats in this post so far.”

I am never one to disappoint. Here is my cat wearing a tiara.

Too long for Twitter

“Far out in the uncharted backwaters of the unfashionable end of the western spiral arm of the Galaxy lies a small unregarded yellow sun. Orbiting this at a distance of roughly ninety-two million miles is an utterly insignificant little blue green planet whose ape-descended life forms are so amazingly primitive that they still think digital photo filters are a pretty neat idea.”

Unowned Reviews

I was feeling a little bit ornery today, and decided to take a look at unowned reviews in Bugzilla (aka patches with a review request “to the wind”, instead of requesting review from some specific person).

After a bit of head scratching to figure out _how_ to get a list of such bugs through the search form, I gave up and use Teh Googlez to get my search query.

When I started there were ~130 requests (in ~110 bugs) across all of Bugzilla. Surprisingly, many of the requests (maybe 2/3rds?) were in bugs that were already resolved fixed/invalid/dupe/wfm, and were thus easily cleared out — along with a comment to take action if there was some non-obvious reason to keep the patch active. (And I use the word “active” loosely as most of these patches were _years_ old.)

For the patches in bugs which were still open, I generally assigned to a reviewer I knew was active in that area (to either close the bug out, perform a review, or reassign to someone else). In a few cases, where patches were really ancient (e.g. 6+ years waiting for a review!) I cleared the review and asked that the patch be updated or bug closed. Reviews of that vintage are simply not useful, and stand in the way of driving this list of reviews to Zarro.

Currently, there are now ~35 unassigned review requests (in ~25 bugs). Most of those are in in Rhino/Tamarin or, and I wasn’t sure what to do with them. I’ll ask around this week.


Firefox flowers

I was at IKEA the other day (for the first time ever!), and juuust as I was about to make it out the door with minimal expense I saw their assortment of fake flowers, and knew what had to be done.

Adds some nice color to my desk at work, when I get bored of it I’ll probably move it so some conference room. 🙂

Make your own!

19 SNÄRTIG flowers (5 blue, 1 yellow, 3 yellow-orange, 7 orange, 3 red).
1 red SMYCKA flower.

I had the red and black filler sitting around from some other store, but it’s easily available. (Note symbolism in Firefox being anchored in the rock of Mozilla.)

My cat, Munchkin, is not available for sale. Sorry.

(…i can haz flowers?)