Paul O’Shannessy (mozilla)

Making restore_on_demand Accessible

2012-05-29T13:00:00-07:00

I know I just wrote about some changes to Session Restore coming in Firefox 15, but here’s another one…

Since Firefox 8, we’ve had a visible preference to restore tabs “on demand”. This surfaced as a checkbox on the “General” preference pane. The checkbox would only be accessible if you enabled Session Restore (by setting Firefox to “Show my windows and tabs from last time”). This was a bit unfortunate because the preference had effects even if you didn’t have Session Restore enabled, namely, that preference was honored when restoring a session following a crash or when returning from Private Browsing mode. In order to change the preference, Session Restore had to be enabled temporarily.

We’ll be changing that in Firefox 15 now that bug 720154 landed. The checkbox has been moved from the “General” pane to the “Tabs” pane and we’ve removed the dependency on Session Restore being enabled.

Session Restore Changes in Firefox 15

2012-05-22T14:23:00-07:00

There are a few changes coming in Firefox 15’s Session Restore. There are a few under the hood changes which should be transparent to anybody using the API, but there are also some changes to the format of the JSON that is exposed.

Form Data

All of the changes have to do with the formdata object that is used to store (wait for it…) form data. Historically we’ve done our best to save the data so that when you recover from a crash or resume a session, we can do our best to get you going again. When we’ve saved the data in the past, it was just in a flat object that looked something like this:

"formdata": {
  "#elementID": "value for form field with id",
  "/xpath/string": "value for form field without id"
}

Starting with Firefox 15, we’ve broken that up a bit further, with id and xpath keys to scoped data. The other key difference is that we no longer prepend # to the element’s id (it was only being used to distinguish id vs xpath). The updated format looks like this:

"formdata": {
  "id": {
    "elementID": "value for form field with id"
  },
  "xpath": {
    "/xpath/string": "value for form field without id"
  }
}

This was a part of making some of Session Restore more usable to other components. In this case it was something originally thought up for Sync to be able to reuse code when syncing tabs between devices.

Better Restoration of `<select>` Elements

The other change will result in better restoration of <select> elements. For the simple case (no multiple) we would simply store the selectedIndex and move on. When restoring, we would re-select that index (unless it was suddenly out of bounds). This resulted in the wrong <option> being selected if <option>s were added or removed. This has been a problem for years with Bugzilla where a new product or component would get added and then people would accidentally save changes to bugs and make changes they didn’t intend.

So now we save the value of the selected <option> and check that when restoring the form. If the value at selectedIndex doesn’t match what we saved, we’ll look through all of the <option>s until we find a match. It’s a simple change but should result in more reliable form restoration.

"selectEl": 1

becomes

"selectEl": {
  "selectedIndex": 1,
  "value": "option value"
}

Backwards Compatability

As with all changes in Session Restore, we’ll be maintaining compatability with the old format for some extended period of time. We will continue to be able to read the old format, but we won’t write it back out. If you’re an API consumer, you should update accordingly. Extension authors should be ready to handle both formats while supporting Firefox 14 and below.

Not Me!

I didn’t write code for any of this! Thanks to Andres and Bellindira from AppCoast for picking up half-written patches and taking them the rest of the way. Tim Taubert helped out a bunch with reviews too. There are other Session Restore changes that this group is working on so there’s more to come!

Building Firefox on OS X Mountain Lion

2012-05-14T00:00:00-07:00

In a similar vein to my article about building on 10.7, here are some issues that have come up while building Firefox on 10.8. I’ve had Mountain Lion installed for a few weeks now and while there were a few hiccups, things have been pretty smooth. Currently I have DP3 update 2 and Xcode 4.4 preview 5 installed.

Xcode & Command Line Tools

If you’ve installed Mountain Lion (MoLo) then you’ve probably realized that you need to reinstall Xcode. This is available on the pre-release software page. Make sure you download & install the Command Line Tools as well. I had issues installing the CL tools from within Xcode, so the separate download was necessary.

`egrep`

You will likely see an error about egrep. We have a “fixed egrep” command we’ve been using since Lion to work around an issue. It seems we no longer need to work around that issue. I have a patch in bug 750574 that makes sure our workaround is only used on Lion.

`clang` & `ccache`

I’ve been using clang to build Firefox for a few months now and have been using ccache for years. While I didn’t have any issue before, on MoLo the 2 didn’t play together nicely. I got build errors while building Growl. Specifically, there were issues with an (un?)expanded NSParameterAssert macro. The fix is to ensure that you set the CCACHE_CPP2 environment variable to yes (export CCACHE_CPP2=yes). Peter Eisentraut explains why this ccache setting works on his blog. We now have a bug on file to make this automatic so you don’t have to set environment variables to get a working build.

homebrew

This isn’t directly related, but I had some issues with packages installed via brew. In my case imagemagick didn’t cooperate. That’s not required to build Firefox, but just a heads up that you may have issues. These steps got everything working for me.

That’s it

There’s a good chance that this isn’t even relevant by the time you install 10.8. If so, then I’ve done my job!

If you’re interested in working on features for Mountain Lion, let me know or follow the tracking bug.

hg amend

2012-05-07T00:00:00-07:00

Mercurial 2.2 introduced a new --amend option to commit. If you’ve ever used Git, then you are probably thinking “finally”. For those of you who haven’t used it, it’s a quick way to modify the last commit.

My workflow with Mercurial is quite different than my workflow with Git, so amend is not going to be as critically important. With Git I typically just have a series of commits on a branch. With Mercurial I typically use a patch queue (because that’s just easier with posting patches to Bugzilla). But there have been plenty of times where I’ve qfinished a patch only to realize I didn’t update the commit message to include the reviewer. Previously this was a 3 step process to fix: qimport -r tip; qrefresh -e; qfinish qtip). Now it’s 1: hg commit --amend. You can do the same with files you forgot to add.

I haven’t played with it much, but the release notes mention that this is a “safe” operation since it uses Mercurial phases. Essentially this simply stops you from editing history in patches that you’ve already pushed to a remote repository.

So there you have it. And a little bonus for people who like to cut down on typing – alias the option to a new command. I’ve been doing this with Git for ages, but now I can finally add it to my .hgrc too:

[alias]
amend = commit --amend

Lion Full Screen Coming to Firefox

2012-03-22T00:00:00-07:00

For the past little while, I’ve been working on adding support for OS X Lion’s native Full Screen mode to Firefox. This was something that others had started before Lion was even released but nobody ever finished it. Since then, every other major browser has shipped support for the feature.

I decided to start working on it in December since nobody else was. Having never really touched Objective C(++) or Cocoa, the task took a bit longer for me than it would have others, but now it’s done and I have more experience with our widget/ code. At the end of the day, the changes need to hook everything up were suprisingly minimal. If you want to check out the process, the work was done in bug 639705.

The patches were landed the other day and are currently in Firefox Nightly. Assuming there are no major issues, this should ship in Firefox 14. Since this landed early in the release cycle, there should be plenty of time to catch any fallout. There are a few known bugs to follow up with (see below) but if you notice any other issues on the Firefox side, please file a new bug (already setup for a new bug in Firefox:General with me CCed).

Adding Support to Your Gecko Application

Since the feature is enabled down in the core, it’s now easy to support Lion Full Screen in your Gecko application. All that you need to do is add fullscreenbutton="true" to your <window>. Thunderbird is in the process of doing this. If you’d like your application to make UI changes (beyond just titlebar hiding), the fullscreen event is fired on the window after the transition is complete.

But wait, there’s more

What I’ve done so far is really just the baseline support. There are a few followup bugs:

support resizing content area
figure out ‘background themes’ support
update menu with new string/shortcut
add top padding?
and surely some other theme related tweaks

What’s the Deal With V8Monkey & SpiderNode?

2012-01-23T00:00:00-08:00

tl;dr Neither are being actively worked on and could use some love.

After NodeConf, development of V8Monkey & SpiderNode slowed. We all got a bit burnt out in the weeks preceding NodeConf and took a little break. Shortly after, Shawn left Mozilla to work at Facebook with Rob on [redacted] and the little break became longer. I was in the middle of planning a wedding & helping the (now-)wife with her company. Shawn & Rob were busy with work and some other side projects. Mozilla opened an office in SF in August, so I stopped riding the train down the peninsula with Shawn & Rob as often. Long story short, we lost interest.

In October I pulled current mozilla-central into the V8Monkey tree & tried to update from there. But some core things changed. APIs changed around Typed Arrays in SpiderMonkey. JSScript stopped being a JSObject which broke some of our assumptions with our implementation. I have a patch locally to try to fix those, but they’re incomplete (it immediately segfaults). It’s been 3 months and the JS engine doesn’t idle, so it’s entirely possible the world changed again.

SpiderNode is untouched. But Node has definitely changed – it’s gone from 0.4.x to 0.6.x and works on Windows! It’s now using a newer version of V8, and further, using more V8 APIs that V8Monkey hasn’t ported. It also looks like Buffers got a pretty big overhaul (I started to merge that, but it got messy). There’s surely some other work that needs to be done.

The Future

There has been some mention of the JS team here at Mozilla implementing the V8 API. Not me or somebody doing it in their free time, but a full-time employee. I haven’t seen that happen, but that’s the best possible outcome. Assuming we have 100% compatibility (which is the only target that makes sense), then the path to reviving SpiderNode from there is easy. Basically we’d just need to fix the build system again to compile SpiderMonkey & use that. Brendan has also threatened to unbitrot V8Monkey, but he’s a busy guy, so we’ll see.

If that doesn’t happen, then the future is grim. I don’t have the time or drive to do this myself. If you’re interested in helping out though, keep reading…

Want to help?

Awesome! Get in touch & I can help get you started. I’m more than happy to get that going because I’d like to see these projects live on. Keep in mind that the real work mostly happens in V8Monkey — it’s 100% C++ and you’re implementing one JS engine’s API with another.

And Just Like That I’m a Firefox Peer

2011-10-26T00:00:00-07:00

Not-so-long story short, as of a couple weeks ago Firefox review policies changed and now I can review any code going into Firefox (browser/)! In actuality though, if a review request came my way in an area I wasn’t familiar with, I would just give feedback and redirect the review to somebody more familiar with that code.

Read up on the new Firefox review policy and see who else can review your patches to Firefox.

max_concurrent_tabs is Dead; Long Live restore_on_demand

2011-08-17T00:00:00-07:00

Since last September, you could set browser.sessionstore.max_concurrent_tabs to 0, and you would essentially have a built-in BarTab. I slipped that in later in the Firefox 4 release cycle as a part of cascaded session restore, but it required going into about:config and changing a preference value (or installing something like BarTab Lite).

Starting with the latest nightly (and soon to be Aurora 8), browser.sessionstore.max_concurrent_tabs is no more. We’re no longer allowing you to specify a specific number of tabs to restore concurrently. Instead we now allow you to either restore on demand, or use the hard-coded 3 tabs at a time value. The new preference is called browser.sessionstore.restore_on_demand. If you had customized max_concurrent_tabs and set it to 0, then restore_on_demand will be migrated to true. Unlike the old preference, restore_on_demand is exposed in the Preferences/Options dialog to make it accessible to a larger audience.

For the details, check out bug 648683.

hg qedit

2011-08-09T00:00:00-07:00

Mercurial queues are still far from my ideal workflow, but they mostly just work so I still use them. I haven’t gotten into qqueues because that seems like even more management I don’t need. If I had a 17 part patch then I would probably give those a go, but I don’t.

Instead I end up reordering the patches in my queue more often that I want. I run vim .hg/patches/series, press a j, k, d, & p a few times, then quit. But sometimes I forget that I’m not at hg root so that doesn’t work (usually tab completion is a good indicator but then I need to cd a bit). Enter hg qedit.

[alias]
qedit = !vim $(hg root)/.hg/patches/series

Just add the above to your .hgrc and you now have a new command which will pop open vim so you can reorder your patches. And of course if you want this to use your editor of choice, you can change “vim” to “$EDITOR” to make that happen.

A couple people have mentioned that there are easier ways to move things around in your queue without editing your series file…

Gavin told me about qup, and Dave said that hg qpush --move <name> achieves the same thing.

Building Firefox on OS X Lion

2011-07-23T00:00:00-07:00

I know there are people here at Mozilla who have been building Firefox on Lion releases for a while now, but I couldn’t find anything that described all the problems. So here I am.

TL;DR: Reinstall XCode & apply a couple patches.

Mercurial

I had originally installed Mercurial via easy_install, so your results may be different. Regardless it was broken. Apparently you can edit the executable and it works, but I didn’t try. Attempting to install Mercurial again failed with Python headers are required to build Mercurial.

Reinstall XCode then reinstall Mercurial and you’re set.

`make` Not Found

Reinstalling XCode fixes that too.

Build Fails with `expected initializer before ‘NS_NORETURN’`

Your build will probably fail. The patch in bug 655339 works to get past this.

Build Fails with `$MACOSX_DEPLOYMENT_TARGET mismatch` error

distutils.errors.DistutilsPlatformError: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.6" but "10.7" during configure

I first thought this was a problem with specifying the wrong target SDK, but I was wrong. This is apparently a python bug. Bug 659881 has more details (and a workaround patch). The bug talks about python via MacPorts, but I’m not using MacPorts nor any non-default python installs.

Simple Tab Stats Script

2011-06-17T00:00:00-07:00

My Firefox usage has always been a bit excessive. I used to open windows to group my different tasks. Then Panorama came along and I started using groups. Then I had too many groups so I started opening new windows. Luckily I set max_concurrent_tabs to 0 so I avoid loading all of those pages at startup (it’s that BarTab-like thing).

My curiosity got the better of me so I wrote a little script to tell me some facts about my usage. There are extensions that do some or all of this, but I didn’t actually want to install anything, I just wanted a quick snapshot of what was up. (That said I might turn it into an about:something sort of extension.) You can see what it tells you – it’s not much but it told me what I wanted to know. My usage was higher earlier today, and I’m sure there are people who are much more abusive of Firefox, so no judging.

Judging me on coding style? I would be. I started writing this in the error console, so I left out whitespace and used shitty variable names. Then it grew up and got all awkward.

SpiderNode at NodeConf 2011

2011-05-19T00:00:00-07:00

Two weeks ago, I traveled with Shawn and Rob to Portland for the inaugural NodeConf. To summarize: it was a great experience and a well run conference. Other people have done overviews, so I’m not going to go there, but read a few here, here, and here. I’m going to talk about SpiderNode at NodeConf instead.

A Quick Aside on the State of Things

We got SpiderNode running on the train ride shortly before getting on a plane to Portland. Under 24 hours before NodeConf. It didn’t pass all tests (still doesn’t) and we had to hack around Node’s Buffers pretty majorly. Ryan’s classic node_chat ran and that was a great state to be in going into NodeConf. As for other demos, those were written right before the presentation so they were a bit unpolished.

Back to NodeConf

As we’d suspected for a while, Brendan Eich was the “Mozilla Person Secret Talk” listed on the schedule. He talked a little bit about ES.next and SpiderNode, with a couple demos. In typical Brendan fashion, it was a lot of information to get in a short period of time. If you want to see the slides, Brendan has them on his blog.

Overall, I think the reception we got was really positive. People seemed excited. Some viewed it as a way to run Node on architectures that V8 doesn’t support (before we left NodeConf I had an email from somebody telling me he had patches to get SpiderNode building on Solaris/Sparc). Others were just excited that this could open up the doors to making Node faster (more benchmarks to compete on). Other people were excited because they just really want block scoping (let).

Other people weren’t so excited. And that’s fair. But there seemed to be some misconceptions about the project and why we were at NodeConf contributing to what felt a bit like disdain.

Selling You

There were some people who seemed convinced that we were there to sell people on using SpiderNode. I think Brendan made this pretty clear during his talk, but here it is again: we’re not trying to sell you. We don’t think you should use it right now. We’re getting closer, but it might be a little while before we suggest people use it for anything besides experimenting. We don’t pass all of the Node tests and we’re almost certainly not faster at this point.

I think Brendan put it best:

We are not out to make a maintained, competing fork of Node, just a friendly downstream that should go away as soon as possible. We aren’t selling anything to Node users.

Splitting the Community

The Node community is pretty awesome and we really don’t want to split it in anyway. I’m sorry that some of you felt that’s what we were doing. If that was you, I’d love to find out what you meant.

The only angle I can see on this one is that the JavaScript one would write using SpiderMonkey’s JS extensions wouldn’t run on normal (V8) Node. This goes back to the experiment thing. If you’re writing Node modules or code you want to share widely using the JS extensions STOP.

Contributing Back

I didn’t see any comments about this topic, but I wanted to make it clear that we’re most certainly going to be contributing back to Node. We created a repository to start that process now. We’re waiting for somebody to handle this pull request, which should make some uses of Buffer faster.

There will surely be other things that can be upstreamed outside of our use of V8Monkey (and the build system changes required to support that).

I hope this clears some things up for people. Let me know if it doesn’t or you have other concerns about SpiderNode’s existence.

About That Hybrid “V8Monkey” Engine

2011-04-14T00:00:00-07:00

I’ve sort of been working on this thing…

Several weeks ago I was curious about why there was no implementation of Node.js using the SpiderMonkey JavaScript engine (the one we use in Firefox). So I tweeted about it and several people said they wanted such a thing and would help work on it.

After some poking around the source, we realized that Node was tied pretty closely to V8, and there really wouldn’t be any way to use SpiderMonkey without ripping Node apart and rebuilding it. Not only would that suck now, but it would likely suck long into the future as Node gets updated. This port would fall behind and nobody wants that.

V8Monkey

So we decided that we would implement the V8 API on top of SpiderMonkey. That way we can just plug our work into Node, and it would “just work”. We’ve been chugging along on this project and have made some great progress. Thanks to John Ford we even have an automated build system running all of our tests on every checkin.

The JS team at Mozilla is also really interested in just having this API around. It has potential for other projects like this, but also raises awareness of API differences and might help push forward changes to the SpiderMonkey API. We’ve already pushed for additions to the SpiderMonkey API (for example, there was previously no exposed API to check ==, only ===). There have also been discussions about turning the SpiderMonkey API into a C++ API (not just C).

It also turns out that we’re not the first people to go down this track. There’s a team at Yahoo! who is very interested in Node and even did a very similar project. They even put the code out there to prove it and it’s been a helpful reference for us. They stopped short to get Node mostly running, while our goal is a bit more ambitious and implement the whole V8 API.

SpiderNode

SpiderNode is what we’re calling our fork of Node. Once we have our V8 binding working, we’ll shift our work over here and focus on integrating SpiderMonkey into the Node build system. Ideally we’d love to get this upstreamed and give Node developers a choice.

We think V8 is great and the fact that Node has become so widely used is a testament to that. But we also think there’s room for competition here. Browser based competition is old-hat. Let’s move this battle to the servers :)

With some hackery from John, we now have a way to build SpiderNode. As of Tuesday node.cc compiles (OMG AWESOME) but that’s it.

Can You Help?

Absolutely. The code for both v8monkey and SpiderNode are on GitHub for now. We have a “hacking” wiki page there, as well as a general TODO page.

We also chat a lot on IRC: #spidernode on irc.mozilla.org.

It’s Not Just Me

That’s for damn sure. Rob Arnold and Shawn Wilsher have been doing most of the heavy lifting. Rob has done some work on SpiderMonkey in a past life and is really good at this sort of language stuff. Shawn is also really smart and definitely no stranger to using SpiderMonkey. This project would be nowhere without these guys. John Ford set up a buildbot for us, which has been incredibly helpful for catching all the tests I break. Having a build engineer helping out has been really great.

Brendan Eich (you may have heard of him) said he’s going to start contributing. My intern Mehdi Mulani submitted a couple patches early on and others have stepped up and are working on patches right now.

My Experience So Far

Honestly, this is the first large scale C/C++ project I’ve worked on. I took ½ a semester of C my freshman year in college (over 6 years ago) and I’ve written some random pieces of C++ at Mozilla. Mostly though, I write JavaScript and before that Ruby & PHP – a lot of scripting languages. It’s a drastic change from what I’m used to and it’s taken me a while to get comfortable. Luckily I’m working with friends who have helped teach me as I go. Learning C++ while making one JavaScript engine work on top of another has been a real sink or swim experience.

It’s been fun though. I really needed something entirely different from Firefox for a little while and this has fit the bill perfectly.

Expect to see more from me and others in the coming days & weeks. And hey, perhaps you’ll see one of us at NodeConf.

Multiple Assignment in JS With Objects

2011-02-25T00:00:00-08:00

Note: Turns out this only works in Firefox since it is the only browser to include versions of JavaScript beyond 1.5. Perhaps something will show up in ECMAScript N/Harmony/whatever.

Alright, JavaScript is pretty cool. There are plenty of “tricks” that still boggle my mind. I just found another cool trick in Mardak code (he would do this…).

This is about multiple assignment in JS. Well, it’s actually about destructuring assignment, but potato, potato.

Hopefully by now we all know that it can be done with arrays.

What I didn’t know is that it can also be done using objects.

This mostly makes sense now that I know it works, I was just a bit surprised. The syntax is strange, but it’s oddly satisfying (and follows from the assignment from an array).

Turns out this works for nested objects too…

Just keep in mind the same rules for object references applies. If I change obj2.foo.dude, that changes e.dude

And last but not least, we can also access values directly with nested objects.

Modifying obj2.foo.dude here will have no effect on g.

Add this to the list of cool things that have been implemented in JS 1.6, 1.7, and 1.8, but yet still aren’t available in all browsers (sigh). Generators, Iterators, array comprehensions, block scoping with let… all cool things that are used regularly within the Firefox codebase.

2 Years at Mozilla

2011-02-23T00:00:00-08:00

On February 23rd, 2009 I started full-time at Mozilla. So much has happened since then, yet it still feels like it was just a couple months ago.

In addition to my time as an intern, I feel like I’ve seen a lot at Mozilla. With Firefox 4 I’ll be seeing my 4th release; 3.0 came out very shortly into my internship, followed by 3.5 soon after I started. 3.6 was my first version where I was around for the whole release, and 4 is so close I can taste it. I’ve had 4 bosses (Connor, Beltzner, Dietrich, and Dolske). We’re now on our 2nd CEO; I’ve seen 1 VP Engineering leave. I’ve met awesome people, and attended 2 summits.

I’ve worked on the password manager, satchel, session restore, the Jetpack prototype, the Add-on SDK, per tab network prioritization, and a whole bunch of random front-end stuff. I ported the Sync extension into Firefox and helped make Firefox work on Windows CE. I’ve even written docshell & widget code (even if it didn’t all get checked in)! The fact that I’ve gotten to work on such varying parts of Firefox is one of my favorite things about my job.

A lot has happened in my personal life as well. I lived by myself for the first time while Amanda was back at school (actually by myself, not counting dorm life or sharing a house). I’ve cleaned up more cat puke than I ever thought I would. I’ve made new friends and grown apart from older friends. I got engaged! I helped my fiancée start a company.

I guess it’s actually been a pretty long 2 years.

Updated Firefox Extension: Always Ask 2.0pre

2011-02-22T00:00:00-08:00

Around the endgame for Firefox 3.6, I wrote an extension called Always Ask to make sure I always got a prompt when quitting. I used it for a while and then forgot about it when it was no longer compatible as Firefox 3.7 (now 4) moved forward.

Now that we’re at the endgame for Firefox 4, and especially with all the changes surrounding the quit dialog, I figured it should be updated. So I’m releasing v2.0pre today which updates the extension to work with component registration changes and quit dialog changes in Firefox 4. This also includes the translations that were submitted via Babelzilla (most of them over a year ago). Thanks to all of you who took the time to translate those strings.

Get it now. Or look at the code.

Why 2.0 “pre”?

Mostly just in case there are any further changes needed to be compatible with Firefox 4 (there better not be though).

Why not restartless?

This would probably work really well as a restartless extension. But I was really lazy and didn’t feel like figuring out the l10n part of that (though it looks like Erik Vold has that figured out already).

New Firefox Extension: switch-to-tab Blacklist

2011-02-18T00:00:00-08:00

Switch To Tab is a pretty cool feature that will be a part of Firefox 4. I didn’t work much on it, but I contributed a bit to it last year (see this post for one example).

For the most part, I really like this new feature. It’s saved me much tab duplication over the past several month. However there are some sites that it doesn’t play well with, namely some JavaScript “applications” and pages with frames. I’ve quietly dealt with it and worked around the issues.

But a couple weeks ago after trying to do multiple Google Maps search, I decided that I’d had enough. I never wanted Google Maps to show up in switch to tab and I was going to write an add-on to make that possible. So I spent a bit of time figuring out how I might do that and looking at this new bootstrapped extension stuff (which is pretty awesome by the way). I didn’t get far enough to make it actually work and stalled. Then I got back to work and fixed some more blockers and promptly forgot about this idea.

Yesterday I started working on it again but my current approach wasn’t working (turns out gBrowser._placesAutocomplete is readonly and it means it). So I asked Shawn about it and he came up with the answer: cheat. Don’t try to intercept the additions to the database, just revert them after the fact. Smart guy.

I wrote a quick and dirty version and iterated. I released a “good enough” version 1.0 last night. “Good enough” meant it was restartless but required restarting to re-process the blacklist preference, which was… dumb. Over lunch today I finished v1.1 to fix that and a couple other small issues.

Let me have it

switch-to-tab Blacklist on AMO

Can I see the code?

It’s on github. I need to clean it up because it’s a bit hard to look at, so don’t judge me too much.

This picture is not worth 1000 words

Previously, that autocomplete result would have been said “Switch to tab:”.

Customizing the blacklist

I’m storing a JSON array of regular expressions (stored as strings which get turned into regular expressions with new RegExp(...)). This is stored in a preference: extension.switchToTabBlacklist.blacklist. You need to edit it by hand for now.

Where’s my GUI

I don’t have visual basic on this computer so I couldn’t make one.

To be honest, I just didn’t care enough to make it. I made this extension for me and I know how to edit a preference. I would gladly take patches though if somebody wants to make one.

About That Quit Dialog…

2011-02-07T00:00:00-08:00

Remember when we turned it off a couple weeks ago? We did that by just flipping the browser.warnOnQuit preference to false. I mentioned that you could get old behavior back by flipping that preference back to true. That’s not going to work anymore.

I just landed bug 629485 to change things again, so pay attention. When we turned off the quit dialog, we took away any way of stopping the last window from closing without any warning, even if you explicitly set the visible pref browser.tabs.warnOnClose which would show the window closing warning (when you have multiple tabs). That wasn’t so cool. So we played around with the logic and made that possible. But in order to do so, we had to change the default value of browser.warnOnQuit to true and create a new preference which controls the quit dialog (browser.showQuitDialog). I know this sounds a bit inane, but there really wasn’t a better way to do it and maintain browser.warnOnQuit == false as an override.

It’s all a bit confusing, so I’ve documented the conditions under which we won’t show a dialog, as well as the rules for choosing which dialog to show. Some of that comment is perfectly clear; the rest requires a little bit of understanding of the code (but it shouldn’t be too hard to figure out if you want).

Don’t expect me to write another post like this. I don’t expect any further changes to how this stuff works.

TL;DR

We enabled the window closing dialog when closing the last window would otherwise just quit (mostly important to Windows and Linux users).
If you want the quit dialog back, set browser.showQuitWarning to true and make sure browser.warnOnQuit is also true.

Update: Feb. 8, 2011: Yup. I fucked that up a little bit. We aren’t showing the quit dialog if you close the last window, even with the prefs mentioned above. That should be fixed in the next nightly.

The New Firefox Default Home Page is Seriously Sexy

2011-01-31T00:00:00-08:00

The new Firefox default home page is seriously sexy. Seriously.

A couple weeks ago Stephen Horlander designed an updated default home page for Firefox. Over the weekend, we landed most of it. So first off, a huge thanks to him.

Mihai Sucan did an awesome job converting the HTML & CSS Steven prototyped into something we could check in, which involved a lot of fun with media queries (seriously, resize your window with it open), as well as a lot of work to make sure it worked with RTL locales.

And then finally, I hooked up the “Restore Previous Session” button. Not the HTML & CSS (that was Stephen & Mihai), just the parts that made it hide when appropriate and work when pressed. Now hopefully a few people realize that feature exists :)

I also can’t forget to mention Marco Bonardo, who hooked up about:home back in August so that we could even get to this point.

Keep in mind, the image I’m showing here is the unbranded “Minefield” version of the page. When loading this in Firefox it won’t look like your computer is going to explode. I think there is a little bit more tweaking that will be done, but it already looks so much better than it used to.

The California DMV has Terrible Browser Recommendations

2011-01-31T00:00:00-08:00

It appears as though the California DMV has not updated their website in the past 10 years…

To be able to use this online application, your computer will need to have one of the latest versions of either the Internet Explorer, Netscape Communicator/Navigator, or equivalent web browsers. For Internet Explorer you must have version 4.0 or higher. We suggest you use Netscape Communicator/Navigator version 6.0 or higher to eliminate any possible printer problems.

— California DMV Browser Requirements

Internet Explorer 4 came out in 1997. Netscape 6 came out in 2000. How far we’ve come…

In related news, the next available appointment (to take the “written” test) at the DMV in San Francisco is halfway through March. I bet I could get a new passport sooner.

Just Quit It

2011-01-21T00:00:00-08:00

For a long time now, if you didn’t have Firefox set to restore your session then Firefox would prompt you before quitting. A dialog with 3 buttons and a checkbox. It looked like this:

That mostly just gets in your way though. You’ve already decided you want to quit. You don’t also need to decide if you want to reopen your tabs next time. So starting with the next nightly (January 21st) and Firefox 4 beta 10, you will no longer see that prompt. Of course if you already checked the box to “not ask next time” you weren’t seeing this anyway.

Essentially, all we did was flip a preference that has been there since Firefox 3 (that was almost 3 years ago for those of you keeping track at home). browser.warnOnQuit was added as hidden preference to override other conditions that might cause a dialog shown at quit. We set that to false. ~~If you want Firefox 3.* behavior, then just flip the pref back to true.~~

If you’re interested, this was done in bug 592822 (it was originally planned as part of bug 588482).

Dude, Where’s My Session?

I know it’s been a while since I wrote about it, but it’s now possible to restore your session on demand after startup. There is work underway to make that feature more visible, namely bug 593421 (to add a button on the start page) and bug 589665 (to add a button in Panorama).

Update (Feb. 7, 2011): We had to make some further changes. We kept the dialog turned off by default but had to do some work with preferences. Setting browser.warnOnQuit is no longer good enough to show the quit dialog. Read more

Use a Pager with Mercurial

2011-01-14T00:00:00-08:00

In the spirit of sharing Mercurial extensions this week, did you know that there’s a pager extension that ships with Mercurial? After using Git for a while and having a nice pager when looking at diffs, I got really annoyed by the fact that I constantly had to scroll my terminal for hg diff. I found the Pager extension and there was much rejoicing.

So turn it on and be happy. It’ll only page when you need to. And while you’re in your .hgrc, enable the also-shipped-but-not-on-by-default Color extension.

hg-prompt Makes My Eyes Happier

2011-01-10T00:00:00-08:00

For a long time I’ve had Git info in my terminal prompt. At Mozilla, we mostly use Mercurial though, so a Git aware terminal wasn’t super helpful. A couple times I tried to hack together something for Mercurial to show me my current branch or applied patch queue. Every time though I either didn’t get everything I wanted or was too lazy to make it work like I wanted (and play nicely with my other customizations).

This morning I started on this problem again. But this time I started by searching for a solution first and voilà, I found hg-prompt. Take a look at the samples and then customize it with the extended list of keywords available.

Amazon and HTML5

2010-11-10T00:00:00-08:00

Apparently Amazon is stepping right into HTML5 and using type="email" in their sign in form. You can see the built-in form validation in action there. This is pretty awesome to actually see out in the wild, especially from such a big name.

Client-side form validation without various JS libraries is pretty cool. Read more about it.

Reset Panorama from the Error Console.

2010-10-21T00:00:00-07:00

Panorama is this cool new feature coming to Firefox 4. Most of the big issues have been fixed, but there’s still the occasional issue with orphan tabs.

Last week I wrote a script that would strip the Panorama data out of Session Restore. That worked but would require a restart. Ian Gilman (one of the Panorama developers) used that script for the basis of a script that worked much better (it actually called into Panorama and told it to reset properly). The only problem is that it left tabs hidden, so it would require jumping into and then out of TabView to bring everything back to normal. I forked that and just added a call that made sure all tabs were shown.

So if you ever get into a confusing state and don’t mind wiping out your current Panorama data, this script is for you:

<3 Firefox Sync

2010-09-24T00:00:00-07:00

Today I accidentally deleted my primary Firefox profile (mostly through user error). I was cleaning testing profiles out via the Profile Manager and managed to delete default. Since that actually deletes the whole profile folder from disk instead of moving to the trash can, I just said “Fuck”. This is a profile I’ve had for a while. It had a lot of history, passwords, bookmarks, extensions. All of it lost in an instant.

Luckily though, I’d set this profile up to use Firefox Sync years ago when early versions of Weave were just being released. At that point I’d set it up for backup primarily. Since then I’ve synced that profile to multiple computers.

The nice thing about it is I lost almost 0 time. I created a new profile, set up Sync, and within a couple minutes had the vital information I needed in my profile. I lost a couple things: extensions, some prefs. I don’t use many extensions so that’s not a huge issue. I don’t even remember what prefs I’ve tweaked, but I’m going to guess not too many. Some prefs were restored by Sync, but there’s only a handful that get synced. I even had all of my tabs a click away on the list of tabs from other computers.

If you’re not using Firefox Sync, it’s built in to Firefox 4 and is also available as an extension.

I Already Love It

2010-09-21T00:00:00-07:00

I already love it. I had to wait several minutes til my 100+ tabs are loaded. Now i can start to surf immediately.

—trolly on mozillazine about Cascaded Session Restore

Cascaded Session Restore + a Hidden Bonus

2010-09-17T00:00:00-07:00

In the tradition of announcing major things on Friday nights…

I did this thing where we don’t load all of your pages at once when we restore your session. That should keep your Firefox (and computer in general) a bit more usable when you start up Firefox with a large session. See bug 586068 if you’re interested in the juicy details.

Other Details

Switching tabs should cause the selected tab to start loading immediately, even if it wasn’t loading before
This works with Panorama (so changing groups re-prioritizes your load order).

Preference Controlled

We load a certain number of tabs based on the browser.sessionstore.max_concurrent_tabs preference. We’ve set the default to 3 for now.

Hidden Bonus

Set the pref to 0. It’s basically a built-in BarTab.

Quirks

We show the page title and favicon at start up, before we try to load the page. So you might see some slightly odd behavior. Panorama’s thumbnail caching isn’t perfect, so there will probably be missing thumbnails at start up if you switch into the Panorama view.

Please email me (link below!) or file a bug blocking 586068 if you see anything weird.

Restore Previous Session

2010-09-10T00:00:00-07:00

I landed bug 588482 today (September 10^th), so starting with tomorrow’s nightly version of Firefox (AKA Minefield), you’ll be able to restore your previous session at any point after start up. This means that you no longer have to restore your whole session immediately at start up. This will be available through a menu item in the History menu, as shown below.

This feature will be in Firefox 4 ~~beta 6~~ beta 7, due out in the next couple weeks.

Details

Restoring your previous session after you’ve browsed around will merge the sessions. You shouldn’t lose any new data by restoring your previous session.
We didn’t break existing behavior. If you have Firefox set to show your windows and tabs from last time, we’ll continue to do so and you won’t even notice this feature exists
App tabs still behave the same.
This doesn’t break any existing APIs, but it does add some new ones.
Discoverability is suboptimal.
You are still prompted to save your session when quitting (assuming default prefs).

Why?

We did this primarily for 2 reasons.

We want faster start up times. By encouraging users to always resume their previous sessions, we give the impression that Firefox takes a long time to load up. But really, you’re loading 20, 50, 100+ tabs and that’s what is slow.
When you’re quitting, you there’s a good chance you have no idea if you’ll need your tabs next time.

(Keep in mind, if you’re reading this post, you aren’t the typical user. You’re probably a developer of some sort who drags your 400 tabs around to each session. You know it’s slow, but you really never got the hang of bookmarks, so you just keep tabs open.)

Privacy

Obviously, in order for us to restore your session, we need to save it to disk. We save this data in a plain-text JSON file in your profile.

We currently consider sessions a little differently than some other browsers. We consider your session cookies (and a few other things) as part of your session. This means we write that information to disk. Under a normal session restore that you’ve explicitly opted-in to, that’s fine. We have a hidden preference (browser.sessionstore.privacy_level) that specifies what level of privacy to use. The default value is 1.

There are 3 levels of privacy:

0 = Save private information for HTTP and HTTPS sites.
1 = Save private information for HTTP sites.
2 = Don’t save any private information.

For deferred sessions, we created a new preference (browser.sessionstore.privacy_level_deferred) with a different default value. Since people are not making an informed decision to restore at shutdown, we don’t want to expose information that can be used to, for example, log in to GMail. This new preference has the same possible values but the default value is 2, so that no session cookies will be restored.

Safari

Yea. They’ve been doing this for ages. But as far as I know, they still don’t allow you to restore your entire session at start up.

Jetpack SDK 0.5 & the Request API

2010-06-29T00:00:00-07:00

Jetpack SDK 0.5 hit the streets last week. There’s a bunch of new APIs in there. I worked on the Request API, which enables a simple way to make XML HTTP Requests (XHR, or AJAX if you must). The API is a wrapper around the Gecko HXR object.

Like jQuery, MooTools, Prototype (or pretty much any JS library), it makes the ugly stuff go away. You simple provide a URL, some data, and a callback, and we’ll do the rest (you can set some more things if you’d like). In the callback, you have access to the response headers and content as JSON/XML/text. Read the documentation for the specifics.

Keep in mind that this is meant to be a simple API. You can’t make complicated requests. For example, you can’t send files with it. The plan is to keep this API simple. It is a first version, so if people need more functionality, we can add more. Or we can take those additional needs and create another API. If you have feedback, please post to the Google Group.

I wrote up a basic example using the Twitter API, which I’ve included below. It’s not too fancy, but gets your feet wet.

Switch to Tab & Closing Empty Tabs

2010-06-15T00:00:00-07:00

Firefox 4 will be introducing a new feature called “Switch to Tab” or “Tab Matches in Awesomebar”, a feature that attempts to see if the page you’re looking for is already open. If it is (and you explicitly select that location bar suggestion), you’ll be taken to that open tab instead of opening a new one. This is great step forward & I’ve already found it quite helpful. I tend to open the same bug several times over the course of a day or week. Now instead of having 3 copies, I can just have one and switch to it quickly.

Even though Blair toiled away on it, there were still a few bugs with the initial implementation. Blair immediately jumped into another small project (redesigning the Add-ons Manager is pretty trivial right?), so many of the followup bugs went unowned. I took two of those bugs; I fixed one a few weeks ago and finally fixed the other today.

The second one is the one that will make more of a difference for user experience. My common workflow goes like this (notice the brokenness at the end):

Open a new tab
Start typing new URL
Sweet, a match! Switch to it.
Repeat 1-3
WTF? I have 15 blank tabs open?

With my patch we’ll now close that empty tab after we switch focus. No more step 5. That is all.

Now Using JSON.parse in Session Restore

2010-06-09T00:00:00-07:00

Back in March, I partially dropped support for sessions from Firefox 2.0 & 3.0. For Firefox 4.0, we’ll be dropping backwards compatibility of sessions for Firefox 2.0 & 3.0. That means that sessions created with nightlies starting tomorrow, will no longer be loadable by versions of Firefox prior to 3.5. With bug 387859, Session Restore will now use JSON.parse instead of evalInSandbox.

So why use `JSON.parse`?

Mostly, it’s faster. evalInSandbox involved going through XPConnect and a whole bunch of object wrapping for security needed to be done. By using JSON.parse, we don’t have to worry about that overhead. We also don’t have to worry about changes made to Chrome Object Wrappers (changes which have broken about:sessionrestore recently).

What does this mean for me? Not Much.

If for some reason you’re bouncing between nightlies and Firefox 3.0, then you’ll want to load your session in Firefox 3.5 or 3.6 before loading it in Firefox 3.0 again. If this describes you, then you should really just upgrade.
The contents of sessionstore.js will no longer have wrapping parenthesis. Those were added so that sessions could still be loaded by Firefox 3.0-.
The keys that were only ever used internally are now excluded from exported sessions. This includes _tabStillLoading, _hosts, and _formDataSaved.

waitForClipboard now available to Mochitests

2010-06-02T00:00:00-07:00

Testing is a part of life. Sadly, that means we have to write tests for things that involve the clipboard. The clipboard is complicated enough with all of this flavor and transferable stuff we have going on. Throw in the fact that the clipboard can be asynchronous (thanks Linux), and it gets worse. We’ve had a number of tests that fail due to expectations that the clipboard be synchronous. Most of those tests have been changed to use a “polling” strategy – essentially waiting for the clipboard to have the expected value. If it doesn’t have the right value after a few seconds, then the test fails. I know of at least 3 tests that use this strategy now, and they all ended up having similar code, perhaps even copy-pasted directly from another test.

Gavin made me use polling for the test in a bug I fixed recently. Then the following week there was a password manager bug that I saw doing clipboard stuff (without polling) so I passed along the “polling is good” requirement.

Instead of making everybody rewrite the wheel, I decided to write SimpleTest.waitForClipboard to take care of this polling stuff for us. It only works with the global clipboard, and only with text/unicode strings (text/plain should work too since it’s available on the clipboard in the unicode flavor). It works by setting the clipboard to a known value (different than your expected value), then polling for that value. After the known value is found, your setup function is called, and we poll again. When we find the value, we add a PASS & then your success function is called. If at any point we timeout waiting for the expected value, we add a FAIL & then your failure function is called.

Following are the arguments and then a simple example test. Hopefully it’s clear how to make use of waitForClipboard in tests you write in the future. I’ve already converted a few tests to use this method. If there are any existing [orange]s that you think could benefit from this, please convert them!

Problem Report: Cat

2010-05-01T00:00:00-07:00

Fact: Cats make things happen that you never expect. Like crash your computer. See also.

A Followup to Flash on Windows

2010-04-27T00:00:00-07:00

Last week I went on a little rant about Adobe’s inane method of installing Flash on Windows (in Firefox). I received a few emails from people pointing out the much better way of installing Flash – just download the .exe installer! Sounds simple, but good luck actually finding that on Adobe’s website (while using Firefox anyway – they do UA sniffing to make you use the extension). I’d known that this existed and this was exactly what I was expecting. I just couldn’t find that page with minimal effort, so I thought I’d rant.

I was also directed towards the Installing the Flash Plugin article on the Mozilla Support website. The support moderators have dealt with the experience I had and spent a lot of time getting the support article right.

That article explain 2 methods of installing Flash, neither of with involves Adobe DLM:

Install Flash through the missing plugin dialog. This involves simply going to a page that requires Flash (without the usual JS fallback, ie. not YouTube) and getting prompted by Firefox to install Flash for you.
Installing via the .exe installer. There is a direct link to the page on Adobe’s site where you can download the actual installer.

So there are sane ways to get Flash installed. Adobe just doesn’t promote them.

How to Install Flash on Windows OR A Cleveland Steamer is a Better Experience

2010-04-21T00:00:00-07:00

I got a 2nd computer at work which I’ve installed Windows 7 onto. So I wanted to finally see the Out Of Process Plugins coming in Firefox 3.6.4. It’s a new computer, so I still need to install Flash. No problem, right? Wrong!

Pretend for a moment that a helpful Adobe customer service agent is helping your mother install Flash:

You need Flash! Go download it.
Oh and by the way, we’re going to trick you into installing some McAffee product that you don’t want! I mean, we’re not tricking you, we’re helping you…
Oh you’re using Firefox? We have an awesome way of installing Adobe products: an extension! You know that way you normally install things on a Windows computer, fuck it! Trust us, this is wayyyy better!
Ok, so since we’re not doing this like you would expect, you’re probably confused by what’s happening now. So we’re going to give you a link to a page that’s going to make you more confused! Oh yea, we’re going to make you edit Firefox options that you didn’t know existed. We’re also going to show you instructions for an old version of Firefox (we know, Firefox 2 came out 4 years ago, but it’s still awesome!), so those pictures don’t match up with what’s actually happening to you. Oh and one more thing. We know you’re installing Flash, but these instructions are for Adobe Reader. I mean, they’re the same, so that big title that says “Adobe Reader Installation Instructions” shouldn’t confuse you at all. If it does, you’re dumb!
Our bad, just click that ‘Allow’ button up at the top of Firefox, but under the tabs. It’s a little yellow. It’s really easy to see. Found it yet? No? That’s cool, I guess we didn’t explain this very well. Moving on.
Sweet, so now we’re installing an extension! WOOOOO!! It’s called ‘Adobe DLM’, not Flash. Oh you didn’t read the fine print? Yea we said we might use the Adobe Download Manager, so we’re doing that. But we didn’t actually want to say ‘Download Manager’ when you were installing – we thought that might get confusing.
Right, so since this is a Firefox extension, we’re going to need you to restart Firefox. I mean, we needed to do that anyway, so let’s just get it out of the way. Go ahead, you definitely want to do that. BUT we’re going to make you figure that out yourself. Oh? You didn’t notice that little bar in Firefox that said you need to restart? Oh well. Find it and press it. We’re almost done now!
So now you’ve restarted Firefox, you get an awesome Windows alert asking if you want to let Adobe DLM make changes to your computer. You definitely want to press ‘Yes’. Still with us? Ok, so just let Adobe Download Manager do it’s thing (yes, DLM is an abbreviation for ‘Download Manager’, you didn’t figure that out on your own?).
And we’re done!
By the way, we’re just going to leave this extension installed. That way when we want to fuck you in the ass, we can. Have a nice day ;)

FUCK YOU ADOBE!

On Rude Recruiters

2010-04-09T00:00:00-07:00

Recruiters are part of how the world works. For the most part, I don’t mind being contacted by them. They’re doing their job. However, I do mind when they lack manners. I probably shouldn’t complain that I’m being contacted, but the lack of manners is one of my biggest pet peeves so I’m bitching. Here’s a few recent examples.

Last month I got one that included:

If for some reason you are not interested …

I think it’s a bit presumptuous to assume I would be interested. It’s probably a form footer, which doesn’t make it any better.

Currently I am crazy searching for 4 positions in the bay.

This is the first sentence from somebody I haven’t ever talked to. No “Hello”, no “My name is and I’m reaching out to you because ”. Also, you’re “crazy searching”? Really?

Earlier today I had somebody call my work extension (which is not in any public place that I know of, nor have I given it to anybody outside the company). How did she get my number? Not only that, but she flat-out lied about what is on my LinkedIn profile:

I actually came across your LinkedIn profile and um… I see blatantly there that you’re um… um… in a position to look for something new.

Go ahead and look at my profile. If you see anything there that says I’m interested in something new, let me know so I can remove it. I have zero plans to leave Mozilla.

Obviously not all recruiters are rude. I like to think we have an awesome recruiting team at Mozilla, and I’ve been contacted by very polite people. I remember the nice ones and I’ve even reached out to the some when friends have been looking for positions.

So recruiters, here are some simple rules for contacting people:

Say some sort of greeting.
Introduce yourself, let me know where you work.
Tell me how you got my name/email/phone number, etc.
Then tell me about the awesome position that you think I’m qualified for and will love.
DON’T MAKE SHIT UP (especially about me, I mean seriously)
You’re going to say “if you know anybody else who might be interested please forward this along” or something along those lines. We all know it.
If you’ve done the above, I’ll respond in a similarly polite fashion and maybe forward the position on to somebody who might be looking for a job.

This is a picture of a burning bridge.

Shaver Facts

2010-03-26T00:00:00-07:00

I had absolutely nothing to do with shaverfacts.com. Absolutely nothing.

(Partially) Dropping Support for Firefox 2.0/3.0 Sessions

2010-03-15T00:00:00-07:00

Note: This does not affect Firefox 3.5 or 3.6 users!

Today I landed a patch for bug 551285, which removes support for certain parts of sessions created in Firefox 2.0 and 3.0. This means that if you upgrade directly from 2.0 or 3.0 to Firefox.next (currently 3.7), you will lose some session data.

The data you would lose is limited to the following:

Form data (2.0 and 3.0)
Session Cookies (2.0 only)
Tab XUL Attributes (2.0 and 3.0)
Session History Post Data (2.0 only)
Session History Owner (2.0 only)

If losing any of this data particularly bothers you, then it’s as simple as upgrading to Firefox 3.6 or Firefox 3.5 first. Alternatively, some session management add-ons could update your session file for you (for example, the author of Session Manager is updating his add-on to do that).

Just Released: Always Ask

2009-12-21T00:00:00-08:00

No, I didn’t mean to press ⌘Q, I just wanted to close that tab. Sure, all I have to do is start Firefox again. You’re right, I didn’t really need those minutes of my life. Yea, go ahead and install those updates I intentionally was putting off. I probably didn’t lose any important information. Oh wait, Session Restore doesn’t save form data on https sites (read: Bugzilla) by default? FFFFFFFFFFFFUUUUUUUUUUUUUUUUUU!!!!!!

Always Ask is an add-on that adds an additional prompt to Firefox when you are quitting. The prompt only shows up if Firefox has determined that you don’t need a prompt. This includes when you have Session Restore enabled, if you’ve changed either of the browser.warnOn* prefs, or if you don’t have Session Restore enabled & are closing multiple tabs. There’s probably some other combination of conditions that change the outcome here.

Since I work on Session Restore, I’ve had it turned on for a long time. In the past I’ve intentionally changed my preferences so that it wouldn’t automatically quit, but that has led to me accidentally setting prefs and disabling the prompt. Then I have the same problem.

So this extension is pretty simple. It’s currently available in English (en-US) but if you’d like to see it in your language, feel free to help out on Babelzilla. Code is available on Github (thanks to hg-git).

Status Update: November 9, 2009

2009-11-09T00:00:00-08:00

Not much exciting happened this past week. We had some out-of-towners (beltzner, johnath, and dietrich) down in the Mountain View office. It’s good to see the boss face-to-face every once in a while. Otherwise it was business as usual.

What I got done last week:

Bug 522545: Third time’s the charm. I finally found an acceptable approach to solving the problem. The problem of… ZOMBIE TABS. Interestingly, this bug is fallout from a different bug I worked on. Read the bug for full details.
Bug 525635 & Bug 521233: Both of these are needed to get Per Tab Network Prioritization into Firefox 3.6. Bug 525635 was about the test that was randomly timing out on Linux. It’s using the test framework added in bug 521233 (waitforFocus in browser-chrome tests), which obviously is not quite right. Dão is continuing to try to find the right fix, but until then, I’ve worked around the issue in a better way than I was. This should make it OK to land everything needed on branch.

What’s happening this week:

Finish bug 522545. Blockers come first. I already have a large portion of the work done & have a good start on tests, so this shouldn’t be too much work.
Land Per Tab Network Prioritization on branch. Not too much involved here, but it has to happen.
Work on bug 526545 (Crash reporter still can send wrong URL when crashing during pageload). This is another blocker. The partial solution should be pretty easy and actually dovetails nicely with the work I’m doing for bug 522545. The full solution might be a bit harder, and might not be worth it.

Per Tab Network Prioritization Update

2009-10-30T00:00:00-07:00

Progress on this was not as fast as I’d hoped it would be. It got stalled behind some other work, going to the CMU job fair, I was poisoned, and I had to figure out how the focus tests work. But that’s enough with the negativity, this is supposed to be good news.

I finally got all my ducks in row and landed the feature today! If you don’t remember what the feature does (or never knew), read through my original article on it. While the underlying implementation changed a fair amount, the basic concept is still the same. The only change made is that we adjust the priority instead of just changing it to pre-determined values. By doing it this way, we won’t interfere with an add-on that, for example, gave Gmail a super high network priority.

We’ve talked about getting this into Firefox 3.6. It’ll need to “bake” a little while on trunk, but it landed cleanly and doesn’t have any compatibility issues, so it should be ok. Then again, IANAD.

Going along with this, I’ve updated the mozNetworkPrioritizer extension to reflect the change in compatibility. It should no longer be used with Firefox 3.7a1pre (and beyond). It will interact poorly with the built-in functionality and could lead to some weird priorities. It won’t actually break anything, but there’s no need to use it. I’ll release another update if/when this goes into Firefox 3.6.

And that’s it. I’ll post again about future landings. Otherwise, I’m going to be working on some session restore blockers and starting another project soon.

Status Update: September 25, 2009

2009-09-27T00:00:00-07:00

I haven’t updated on the blog recently, so here’s the past 3 weeks all at once.

The week of September 7, I was working on a couple blockers.

The week of September 14, I was in Pittsburgh recruiting at the Carnegie Mellon TOC (job fair). I also did some work on Per Tab Network Prioritization (bug 514490) and a password manager performance bug (bug 492197).

This past week I worked on a few different things. I finished the password manager bug (which I hadn’t finished because of a non-syntax-error-syntax-error). While helping Henrik as he was using the storage API, Shawn mentioned that one of the methods I used was deprecated (though never explicitly). So I filed the bugs and fixed the places that used the deprecated code (hint: use executeStep() instead of step() and don’t use mozIStorageStatementWrapper). Filing the bugs took longer than fixing them.

But all of that was unrelated to …

Per Tab Network Prioritization Status

Progress

Made it a JS module. This was advice from Dietrich to cut down on overhead. Since it was only being used from JS code, there was no need to use XPCOM.
Made it pref enabled. Right now it’s browser.networkprioritizer.enabled but that’s easy to change.
Got a first pass look from Shawn, fixed a few things up.

Next Steps

Reviews. It seems like Boris is the guy for the job. Still need a browser person. Gavin said sometime after Fennec stuff, Connor said 2 weeks. Dolske said “soon”, so he’ll probably be the lucky guy, even if he isn’t a peer.

Per Tab Network Prioritization

2009-09-04T00:00:00-07:00

First! (before you get distracted) Try server builds! and the extension! (Firefox 3.5+)

The Idea In Summary

An idea that’s likely been tossed around before has been brought to the forefront more recently by Firefox’s newest designer Alexander Limi, the idea of per tab network prioritization. The premise of the idea is that what you’re doing right now is more important that what you were doing 5 minutes ago. So to account for the relative importance, we should make what you’re looking at right now load faster. This is really part of a grander scheme to improve perceived performance, but has been reduced to try to make some improvement achievable for Firefox 3.6.

In More Detail

For this pass, we divided tabs into level of importance (shown in descending order):

Selected Tab in a Focused Window
Background Tab in a Focused Window & Selected Tab in a Background Window
Background Tab in a Background Window
Any Tab in a Minimized Window

For the most part that makes sense, except for maybe one thing: the 2^nd^ level of importance has 2 items. We decided that (at least in general terms) background tabs in your current window and the focused tab in a background window should get the same level of network priority.

I then used this ranking to assign relative priorities. You can read more in the implementation section, but otherwise you can skip down to the progress report.

Implementation

My original plan was to do this all in browser/base/content (browser.js, tabbrowser.xml), but I ran into a roadblock of some sort. So I wrote it as an extension. After fixing an observer topic, I could do this with relative ease. I set my JS up much like the SessionStore component, observed a number of topics, and listened for a number of events. I was using an observer topic (xul-window-visible) which I was told I shouldn’t use. When a tab was selected it’s network priority gets bumped up and the previously selected tab gets dropped down. Same concept for windows.

I had to create some new events so that I could accurately know which window was focused. Then I brought it into our actual tree instead of living externally as an extension. I cleaned it up a bit, made sure I wasn’t doing to too much, and then finally got around to filing the bug. I would go into further detail, but it’s not super interesting. However, if you are interested, take a look at the code.

While there are some implementation details to improve upon (or just straight up change), it’s doing what it was supposed to be doing. At this point I could move this back into browser/base/content but since it’s working, there’s no value in it (until we decide the project is a final go).

Progress Report

Initial results showed some improvement when loading large groups of tabs. It was most noticeable when loading many tabs from the same site (e.g. the default BBC livemarks). It was somewhat noticeable during a typical (for me) session restore. There was no difference during normal browsing.

But I’m just one person. I know this is all the way at the bottom of this article, but PLEASE PLEASE PLEASE use a try server build (or the extension) for a little bit and see if there’s any noticeable difference. Even if it’s just to load up that 500 tab session you’ve been building up over the years.

Next Steps: Get Feedback! If people use it and the results are positive, this will get more attention (tests, better implementation, checked in). If it turns out that we didn’t quite achieve what we were hoping, then this will get shelved or used as part of another project.

So again: try server builds and the extension!

Updated September 4^th^ with links to the extension

Oops, I Broke That

2009-08-28T00:00:00-07:00

While making the “Set as Desktop Background” feature work on Windows CE, I accidentally broke it on other Windows systems. OOOOOPS.

This went unnoticed for ~3 weeks on the nightlies! It was even in Firefox 3.6 alpha 1. The fix was easy and was checked into trunk today. It’ll be checked into the Firefox 3.6 branch soon.

I don’t think mistakes like that are too uncommon, especially in areas where testing isn’t automated. We probably have Litmus tests for this so it would have been caught before a final release anyway, but still…

This just goes to show how important testing is! (And yes, I filed a bug to add tests here)

This also goes to show just how little people use that feature :)

Better Session Restore Behavior

2009-08-06T00:00:00-07:00

Last week bug 354894 landed to, surprisingly, little fanfare. It’s a big deal though (more so on Windows & Linux).

Ever since Firefox introduced Session Restore, there has been one particularly annoying problem: if you close your last browser window but accidentally left a non-browser window open (eg. Downloads), then your session was fucked. End of story.

Well, no longer. Nils Maier (co-author of DownThemAll) finally got fed up with this problem & decided to do something about it. This is the first “major” piece of code he’s contributed, so a round of applause.

A super quick summary of the changes (assuming you have enabled session restore):

If you leave a non-browser window open, just close it. Your session will be saved (assuming you aren’t on OS X anyway).
If you’ve gotten down to that last non-browser window & realized your mistake, opening Firefox again (e.g. from the start menu) reopens your last closed window.

As a tangential comment, it’s things like this that really make me proud to be a part of the Mozilla community. So much of our browser & platform comes from people like Nils who give their time freely to help make the web a better place.

Update: Minor changes based on email with Nils.

Undo Close Window Has Landed!

2009-04-24T00:00:00-07:00

I’m happy to announce the landing of Undo Close Window. This adds a menu & keyboard shortcut for reopening your previously closed windows. By default we store 3 windows (though sometimes more due to special cases involving pop-up windows). I’m not going to go into further implementation details (because really, I know you don’t care), but if you’re interested, you can take a look at the patches on the bug.

A Little History

Sometime before Firefox 2, there were APIs in place for handling recently closed windows. The only thing missing at that point was the front-end work to tie it together. But that never happened. Instead, since the code wasn’t even being published for extensions to use, all that was happening is that we were eating memory for no good reason. So the code was taken out late in the 2.0 development cycle.

Bug 360408 was added for Firefox 3, making it possible for extensions to be able to implement their own Undo Close Window if they wanted. The description of that bug was unclear though, since it didn’t actually adding any APIs, it just made sure the data was kept around long enough to be saved by somebody else.

Along comes Bug 394759 – Add undo close window feature, which sat untouched for almost a year. After I finished the primary project I worked on during my internship, I still had a week left, so I looked for bugs that I found interesting and allowed me to explore a new area of the code. I found this bug and wrote a “working” patch over a weekend. At that point I was really surprised that we didn’t have this already. We’ve had Undo Close Tab for a while, and this seemed like the sensible next step. In all honesty, somebody familiar with the code involved here could have written that patch in an hour or two. That’s when I found out that I had essentially reimplemented the code that had been taken out and added the front-end to it.

I worked on it a bit more before I was done interning, then went back to school and time to work on this became increasingly rare. I dropped the ball a bit, and then suddenly we were at string freeze, and this wasn’t done. Fast forward a few months; I graduated & started working for Mozilla full time. I found out we were still going to have another string freeze for beta 4, so I got my patch out of bitrot and continued working on it. It needed more work and testing by then due to Private Browsing and a few other changes that were made. Strings went in right before we froze them & the actual patch went in very last minute, and only because code freeze had slipped for other reasons.

A huge thanks to Simon for all the reviewing he did and help he gave me, Dietrich for the heroic “today is code freeze” review and help, Dão for fixing the problems that popped up as this had a rocky landing (there was no time to bake on trunk), and Beltzner for approving this without the normal bake time.

Changing Tab Load Order

2009-04-01T00:00:00-07:00

During the Firefox work week last month, somebody had the idea of loading visible tabs first. It’s one of those things that just make sense. Since I had done some work in the SessionStore component before, I volunteered to head up this task.

What does it do exactly?

When you open Firefox using session restore (and through some other paths), you often load several tabs. I know I’ve personally restored windows with 50+ open tabs. It takes a lot of time to load 50 tabs. One optimization that was done previously was to (roughly speaking) prioritize the selected tab, so that it would in theory load first. This change make it so that the tabs visible in your tab strip are also prioritized.

How does it work?

When we were doing this for just the selected tab, it was extremely simple – we just reordered the array of tab data so that the selected one was first. Now we prioritize a set of tabs (keeping the selected tab first). That’s it.

To be clear, this does not actually improve performance. All it does is make the browser feel faster. But hey, isn’t that just as almost as important.

Go ahead and try it out. It’s been in Minefield (mozilla-central) for over a week and landed in Shiretoko (mozilla-1.9.1) yesterday.

Is The Tree Green? For Your Desktop

2009-03-24T00:00:00-07:00

GeekTool is awesome. Is the Tree Green? is awesome. So together they are SUPER AWESOME!

Python?

Historically, I’m a Ruby guy, but I started learning Python for a Django project I’m (barely) working on. So I picked up a book here at work & decided to flex my pythons a little bit. You can laugh, it’s punny.

The first pass of this took me ~20 minutes, and I just tidied it up this morning so it would take command line options.

How?

If you’re reading this and actually need to know whether or not the tree is green, then you should be able to figure it out. GeekTool is OS X only, but there are similar programs for Windows and Linux.

It’s easy enough to do what I did in the image above. The program can take 2 arguments treename and output. Run it with -h for usage.

Code?

A big thanks to Justin Dolske for Is the Tree Green?. He deserves more credit for this than I.

Here I Am, Back Again

2009-03-10T00:00:00-07:00

I’m now into my third week here at Mozilla, working on Firefox. It’s been a tiring 2 weeks so far, but I’ve enjoyed every second.

For those of you who don’t know, I was an intern on the Firefox team last summer. I primarily worked on the password manager and a performance analysis tool. I was offered a full-time position soon after the summer ended, and while I did some looking around, I realized that I wanted to be at Mozilla. I loved the company, the people, and the work I would do — so overall it was right for me.

After an extended winter break, I flew out here with Amanda on February 17^th^, a Tuesday. Amanda had been looking at apartment stuff like a fiend, and while I helped, she found a bunch of great places for us to see and did the real work with that. So we spent Wednesday & Thursday looking at ~20 apartments. CitiApartments may (apparently) be the spawn of Satan when it comes to housing in SF, but Hilary was an incredibly helpful agent, if perhaps a little unconventional. It turns out that the apartment we really wanted was the first one we saw on Wednesday morning. Friday was spent making sure our application went through, and jumping through hoops to get my money from my bank in Pennsylvania in order to get certified checks. It all worked out; we signed our lease on Saturday and moved in Monday/Tuesday. We’re working on making the place a bit more homey, but it’s coming along and hopefully we’ll have a little housewarming when there are places for people to sit.

Back to Work

I joined the team as we’re wrapping up Firefox ~~3.1~~ 3.5, and since I’m already relatively familiar with the code base, I got to start working on fixing blockers & participating in sprints. My first week was also a Firefox “work week,” where the Firefox team physically gets together (we’re spread out around the world), and gets stuff done face-to-face. We came up with a bunch of good ideas for what we want to be and how to make people excited about Firefox — that’s where our sprints came from.

I look forward to working with everybody here and meeting those of you who I haven’t met yet. Remember, I’m not an intern this time around :)

Making the New Password Manager Storage Faster

2008-08-28T00:00:00-07:00

When I first wrote the new storage module for the Password Manager, I took a few “shortcuts,” trying to keep my code DRY. Partially this was because of the first patch by Mrinal Kant, but mostly it was because I like to reuse code. This bit us just a bit.

I mentioned in my first post about this change that we were initially considerably slower in the critical countLogins method. While it got improved before being checked in, it was still marginally slower (milliseconds on an abnormally large dataset).

As I said before, this was most likely since we were doing a SELECT * on the moz_logins table, and looping over the results and counting. This allowed me to reuse more code. Loops are a kind of slow, and since this was so important, I decided to speed it up.

I filed a bug just over a week ago entitled “storage-mozStorage should use COUNT in countLogins” – which pretty much explains what the solution to the above problem. I created a patch which essentially just switched the mosStorage module to use SELECT COUNT(1). I reran the performance tests I created and we’re doing much better now. There’s still a miniscule loss in speed from the legacy storage module, but at this point, we’ve done all that we can, and where the difference was milliseconds, its closer to millisecond.

This was checked in today (thanks Justin!).

And that’s it. I have another patch in the pipeline and hopefully I’ll have time to get it finished, approved, and reviewed for the freeze (whenever that is now).

Password Manager now uses mozStorage

2008-08-18T00:00:00-07:00

The other day my patch landed switching the Password Manager to use mozStorage (our wrapper around SQLite). The bug had been up on Bugzilla for a long time, over 3 years, when I came across it at the end of June. I had been doing some Password Manager related work already by that point, so I decided I would do it. This is the story of that bug: the process, the hardships, the code (at least a bit). Keep in mind I was also doing work on my DTrace Treemaps at the time, went to Summit, and encountered more edge cases than I wanted, so this took longer than expected.

Quick Features & Change Summary

Some of this is discussed further down, so bear with me. One of the primary differences in the switch to using mozStorage is that we now store data in a database. Previously we were storing data in a text file, using lines and periods to separate data fields. Open signons3.txt in your profile directory and take a look at it (assuming you’ve saved a password before). All information was kept in memory, and when a new password was saved, the whole file would need to be rewritten. The same thing happened if you ever removed a saved password. Using a database means that we don’t have to keep any (potentially) sensitive information in memory. It also means faster reading and writing since we don’t have to read the whole file every time. These speed boosts are apparent especially in the speed tests, attached to the bug and summarized below.

Since this is really just a drop in change that must implement an API, to the outside world nothing has changed. Although the inner workings are different, it’s the same to anybody who happens to use it (extensions or other parts of Firefox).

v0.1 – The beginning

I began work by really taking a look at the legacy storage module to make sure I knew what was supposed to be happening. Then I looked at the initial attempts by other developers. The first attempts were made before Password Manager got rewritten, so those weren’t relevant. Mrinal Kant came in (over 2 years after the first patches) and wrote what I used as the basis for my code. I don’t think I ran it as it was, but it looked functional, at least at the core.

I actually started by just copying the legacy storage file, removing all of the code from methods that would need to be changed, and started fresh. I copied in some code from Mrinal’s work and used some of the conventions, but the bulk of it was rewritten. I opted to use the wrapper we have for Storage, which makes it easy to do parameter replacement. This also automatically binds the parameters to a type – so when you give it a string, it will ensure it’s treated as a string. It’s very handy.

This first version “worked” (at least as far as I remember), though it definitely had problems. I brought it up at our weekly status meeting and it became one of the “nice to have” features for 3.1. That gave it some attention it needed and I got some quick feedback from Shawn and Justin.

v0.2 – Database details

One of the primary changes here was some of the database stuff. Shawn had pointed out that I needed a way to version the database. All I had was a method to create the tables. In order to future-proof this, I needed to make sure the schema was stored somewhere and there was a procedure for migrating the database.

I took a look at nsContentPrefService (which stores your preferences for specific sites, like remembering zoom settings) since that was another component using storage and written in JavaScript. I “hijacked” the code related to the database stuff, and modified it a bit to fit my needs.

The other major change here was to replace var with let – “let is the new var” as my shirt says. A number of other changes were also made – cleaning up queries, hard-coding the table names, and making sure I was using statements correctly.

v0.3, v0.4 – Cleanup & Optimization

These versions were pretty light – mostly involving cleanup. modifyLogin and the process involved got improved. I also reduced the number of queries we were making by hand and so all SELECTs were done from just 2 places (one for each table).

v0.5 – Importing

v0.5 focused on importing from the legacy module. The basics were in the original code Mrinal wrote, but all of the edge cases were difficult to handle. The one case that caused a lot of problems were the “user has a master password, but presses cancel when we import”. We needed to handle that gracefully, and Justin and I decided the best way was to introduce a _deferredInit method, which did the bulk of the initialization work. At the beginning of each public method, we then check the initialization state and try to import again. It can get annoying, but everything about the master password is annoying.

This also resulted in a couple bugs being spun off to help us with importing: one bug was just a few lines added to the legacy module and the password manager UI to handle an additional error, and the other was just to ensure the legacy module didn’t create an empty file if it was never used.

v0.6 – Tests

I finally got to writing the tests, which involved a lot of copy & paste from the legacy tests, then making small modifications. It’s not the most efficient way, but it works ok. Since the mozStorage module works slightly differently, the code duplication is a necessity for now. In theory they can be cleaned up, but that’ll be a task for the next intern :)

At this point I thought I was pretty much done, and I was. There were still a few problems though, and also not quite enough test coverage.

v0.7, v0.8 – Cleanup, Tests, Corrupt Databases

v0.7 involved a lot of cleanup and adding tests. v0.8 was an important milestone in that I finally added the handling of a corrupt database. Before this point, if we encountered a corrupt database, we would fail and then as with a failed import, just try again and again. This was bad, really bad. So a “thank you” to Shawn for catching that. Now we backup the corrupt database and just create a new one. It should be difficult to get a corrupt database, but just in case (and to cover the case when people think they know what they’re doing, but don’t).

v0.9, v1.0 – Performance

In one of the recent status meetings, Mike Shaver asked me about performance. At that point I hadn’t really done much except throw it up on the try server. The try server gives decent ball park figures, but it’s not perfect. So Justin worked on getting Standalone Talos working while I wrote some XPC shell “tests”. I discovered that while we were generally faster – faster init, faster add, faster remove – we were considerably slower for countLogin, which is a critical path, since it gets called on every page. Over 90% of the that time was actually spent initializing nsLoginInfo objects (since I tried to reuse code). This got improved, though we are still a couple milliseconds slower. This could likely be improved a little bit since we are still doing a SELECT and looping over the results. A little bit more work needs to be done that way, so making the query use COUNT would cut that out. Maybe I’ll write another patch to do that before Beta 1. For now though, we’ll keep doing it how we’re doing it.

And that’s all… almost

After this got checked in, the Windows boxes turned orange on Tinderbox. This was because of the tests (trying to delete files). Justin and I thought we had a quick fix, committed that. As I was packing to come home, I got pinged on IRC since the boxes were still orange and it was my fault. So the tests for my changeset got backed out and we switched back to the legacy module, but the code was still in there.

On Sunday, my module was re-enabled (thanks Justin!). There was another hiccup related to packages-static, but that was fixed as well. If you have any problems please report them on Bugzilla.

DTrace and Treemaps: Part 1

2008-07-24T00:00:00-07:00

One of my goals for this summer at Mozilla was improving performance when Firefox starts. Admittedly, I’ve done nothing of the sort. Instead I’ve tackled this from a more general angle – making a tool that uses DTrace and creates a treemap of the output. This serves as a way of analyzing performance in a very visual way. Before I go further, a little background.

DTrace

“DTrace is a comprehensive dynamic tracing framework created by Sun Microsystems for troubleshooting system and application problems in real time.”1 It was originally in Solaris and OpenSolaris, but has since been ported to OS X and was included in Leopard. In a nutshell, it lets you take a look at the inner workings of applications and kernel activity, with a low overhead. You can do everything from looking at file IO to time spent in functions to analyzing system call times. It’s pretty powerful and I’ve only just touched the surface of it.

Developers at Mozilla have done a lot of work getting probes into Firefox so that we can take advantage of all DTrace has to offer. One of these places where probes have gone is into JavaScript execution. This opens up the doors to using DTrace to track what’s happening in JavaScript, which is especially useful at Mozilla since a lot of our front-end code is JavaScript.

Treemaps

“Treemapping is a method for displaying tree-structured data using nested rectangles.”2 In other words, pretty damn cool. One of the coolest uses I’ve seen recently is newsmap – which takes the news as aggregated by Google News, and builds a beautiful representation of what’s “hot” in the news.

What I’ve done

The work that I’ve been doing so far is pretty simple. I’ve taken the output of a single DTrace script (js_functime, available on Brendan Gregg’s blog) and used that to create a treemap. This DTrace script measures the time spent in Javascript functions. It’s not the most accurate measurement since the output is the overlapping times, but it’s still a good place to start. The output contains the number of times each function was called, the average time spent in the function, and the total time spent (across calls). From there I build these treemaps.

I’ve used a modified version of the RubyTreemap gem to create SVGs of this output. I create 3 different high-level maps, each representing the bits of information I get (count, average time, total time). Each of these maps is made from a tree 3 levels deep (though the root node is insignificant). The topmost level is the file from which the function is in. The second level is the function name. Size is determined from the measurement type (thus 3 maps). Each of these maps can then be broken down further, stepping into each individual file. So from these 3 “index” SVGs, I’ve linked down into the second level, and a new SVG is generated for each file, making it a bit easier to read the smaller nodes. Colors are consistent between runs and based on an adapted hashing algorithm.

I can’t hand out the source yet since the original RubyTreemap is GPL’ed and I’m not ready to redistribute. The changes aren’t huge, but are very focused for this task, so might not even be able to be merged back. Also, my code is pretty ugly right now and that would just lead to embarrassment.

So without further ado, here’s the page on playground: DTrace Treemaps. Keep in mind that this is not complete and what you see may very well change soon. Here are the direct links to the SVGs if you are a bit impatient: count, average, sum.

Future Directions

From here I plan on using the output from some of the scripts in the DTrace Toolkit to create other visuals, likely more treemaps. I also need to do a number of things to package this nicely so it’s easy to adapt and use for different DTrace outputs. Last, but certainly not least, I need to make the code much better – it’s my own personal Frankenstein right now, and needs to suck less.

¹ Wikipedia DTrace article

² Wikipedia Treemapping article

On Open Source

2008-07-20T00:00:00-07:00

Two weeks ago, while working on a project yet to be revealed (unless you happen to stalk me on Bugzilla – I’ll write about it soon, I promise), I happened to make Minefield seg fault. I was talking to Shawn Wilsher about what I was working on, so he had some familiarity with the code, and told me it shouldn’t be crashing. But it was. Shawn told me to file a bug, create a test case, and get a stack trace with GDB. I was a bit annoyed because it took time away from what I was working on. But I did all that, filed the bug, and went along my way.

The other day, I got to work and found a few Bugzilla emails waiting. Apparently somebody had written a patch for the bug, and it had been r+ed and checked in. I figured somebody was looking at it, but a lot happened at once. So I took a look at the commit log and it turns out that the test case I had written had been included! That makes perfect sense – we want to keep the test around to make sure we don’t regress in the future – but it still surprised me. I never came to Mozilla expecting to touch such a random place in the code base. And while I wasn’t fixing the C++ code, I was still contributing. It felt good.

I think that is part of the power of open source.

Introducing LOLcanvas

2008-06-26T00:00:00-07:00

Work has been going forward in (what will likely be) Firefox 3.1. While there are definitely changes happening in the front-end, there are also a number of changes happening in the backend (AKA Gecko 1.9.1) as well.

Gecko 1.9.1 is going to have even more improved CSS3 support, as David Baron writes about. He’s landed support for some additional CSS selectors. Rob Arnold has recently done work on border-image, and I know at least one other intern is working on some CSS3 stuff.

More relevantly though, Eric Butler has done work on canvas support. One thing that he’s worked on is getting the canvas element text drawing up to speed, and more up to spec. I had some free time so I worked on a little demo to show off the new stuff.

It’s called LOLcanvas and uses canvas to draw text on a flickr image, client side. This is similar to another project I worked on before – flolcatr – however now it’s all done right in the browser. Anyway, a picture is worth a thousand words, so here:

The details are on the LOLcanvas homepage, so give it a try and have fun. If you have some additional phrases to add, let me know. I’ll be throwing the readable source up somewhere soon so that you can see exactly what’s happening.

Original image is CC licensed and available here.

It’s Awesome for a Reason

2008-06-18T00:00:00-07:00

Firefox 3 came out yesterday to much fanfare and a world record. The world seems to like it, at least in general, though I have heard a bit of complaining. One thing in particular: the Awesome Bar.

This has been the number one complaint I’ve heard, and to be fair, I can’t blame people. When I first downloaded a beta (or maybe a nightly) back in January, I HATED the Awesome Bar. I spent a couple hours with it and bitched to Rob (who was and still is an intern). I just wanted URLs to be matched as they always had been, with the first few letters and then a bunch of arrow pressing as I chose the right page. By the end of those hours I was frustrated as all hell and wanted out. Rob told me about the oldbar extension – which makes the Awesome Bar behave much like the old location bar – and installed it. I used Firefox & Safari roughly equally over the next couple weeks, and then I interviewed with Mozilla.

During one of my interviews (with Mike Connor I believe), I was asked, “If you could change one thing about Firefox, what would it be?” I thought about it a second, and the first thing that came to mind was my new found hatred of the Awesome Bar, so I said that. I explained myself, and said some of the things that I said to Rob. My biggest gripe was that I just wanted URLs to be matched before titles of pages. Mike talked a bit about how it worked and how it used machine learning to adapt to how I used it. So if I just behaved like I used to and chose the page I was looking for, it would remember that for next time. He said it was still being tweaked and it wasn’t perfect yet, but that I really should give it another shot.

So I did, and since I knew a little bit more about it, I felt a little less apprehensive about using it. So I set out to “train” it. I bit the bullet and got some inaccurate results over the next week or two. At one point in there I opened my browser and could not for the life of me think of the domain or URL for a page I knew I had been to a couple days before. I did however know what the page was about (it was something specific about Java or some such nonsense for an assignment). So I just typed the topic into the Awesome Bar. Luckily the word I was thinking had been in the page title, and ~~viola~~ voilà – the first result after I had typed the word was the exact page I was looking for. It had proved itself to me. I probably would have spent another 20 minutes trying to remember exactly what I searched for on Google. I’ve been using it since and absolutely love it.

So just give it a shot and quit complaining. Yes, it is a complete paradigm shift. But it’s not called the Awesome Bar for nothing; it really is awesome once you give it a chance.

My First Patch

2008-06-12T00:00:00-07:00

Today I put created my first patch for Firefox. It’s nothing major, but it still counts. It still hasn’t been r+ed yet (c’mon dolske!). Basically, it creates a public function that exposes a private function in the Password Manager. This makes it so that a user can have Firefox remember passwords, disable the feature to autofill login forms on page load, yet still expose the functionality to fill in the form. This opens it up for an extension to do that work.

I think Justin probably said it better:

…it seems like a legitimate use case for those who want this as an option. At the very least by adding some flags to the existing code, so an extension could drive the UI side. [Eg, currently the password manager form-fill code can only be triggered by page loads, but it should be easy to expose this as an interface for extensions.]

Better?

So if you’d like to read some more about it, there’s the discussion on Bugzilla and ~~the diff for the patch~~. It’s not checked into source yet, but soon. So yea, this isn’t terribly exciting… unless you’re me.

Update: The original patch got canceled since we decided it would be better to expose just the functionality to fill a form as opposed to the whole document, at least as a first step. There’s a ~~new patch~~ in that’s now waiting for a review.

Update 2: I was very preemptive here. I should have just waited until it actually got committed. I ended up getting r-ed a couple times, but it made it in. So without further ado, the changeset.

Interning at Mozilla: Week 1

2008-05-31T00:00:00-07:00

I’ve just finished my first week at Mozilla. So far it’s been a blast. They’ve put us up in a really nice temporary living apartment complex (pictures and yes that is a 40 person hot tub), the other interns are all really nice, and well, it’s California.

This week we had a poker game / movie night. I was in on poker and turned $10 into $30, which should keep from an ATM a little bit longer. They’ve also been feeding us lunch this week; there’s a stock of good snacks & cereal, so I don’t have to eat breakfast before work (although I have been).

Anyway, on to Firefox.

So I am on the Firefox team for the summer. My initial goals include working on profiling startup and improving shutdown. Neither of these are one day tasks, not even 1 week. In fact, both seem pretty lofty and fun to work on.

The improving shutdown part is where I’ve been focusing first – it’s something that has bothered me personally. The behavior is both inconsistent and can be pretty annoying. For example, if you close the last window vs. doing File|Exit (and have “Clear Privacy on Exit”) checked, you will have different outcomes when you try to restore your session. Not only that, but there are several different dialogs that can pop up. Then take into account leaving the Downloads window up when you close the last window — your session restore is screwed (at least last I remember). That is not the expected behavior.

So all this week I’ve been digging through the Firefox source code with MXR. I haven’t written a single line, just reading & taking notes. It’s not simple. Shutdown (or “Exit” or “Quit”) goes through a number of steps and then broadcasts a quit-application-requested message. Other objects observe specific messages, so all the ones that observe quit-application-requested are then triggered. Some of these in turn trigger dialogs, set preferences, close windows, and so on. Assuming all goes well there, quit-application-granted and subsequently quit-application are broadcast. These events can be triggered in either JavaScript or C++, not to mention that sometimes the JavaScript is being called from XUL, or XUL is “run” from Javascript. It’s even more complicated than it may sound here, so maybe in a future post I’ll break it down even more. I still haven’t finished working it out completely. I’ve looked at some of the “Close Window” code as well to track down where differences lie and how that can be made more consistent… All in all, it’s hurts my brain a little bit.

That said, it’s been a fun (albeit exasperating at times) week and I’m looking forward to the rest of the summer.