zpao.com | blog

Status Update: November 9, 2009

paul@zpao.com (Paul O’Shannessy) — Mon, 09 Nov 2009 18:26:39 GMT

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

paul@zpao.com (Paul O’Shannessy) — Sat, 31 Oct 2009 01:54:13 GMT

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

paul@zpao.com (Paul O’Shannessy) — Mon, 28 Sep 2009 06:11:49 GMT

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

paul@zpao.com (Paul O’Shannessy) — Fri, 04 Sep 2009 23:53:19 GMT

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

paul@zpao.com (Paul O’Shannessy) — Fri, 28 Aug 2009 23:04:56 GMT

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

paul@zpao.com (Paul O’Shannessy) — Fri, 07 Aug 2009 17:47:08 GMT

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!

paul@zpao.com (Paul O’Shannessy) — Fri, 24 Apr 2009 21:32:21 GMT

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

paul@zpao.com (Paul O’Shannessy) — Wed, 01 Apr 2009 17:38:48 GMT

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

paul@zpao.com (Paul O’Shannessy) — Tue, 24 Mar 2009 23:08:39 GMT

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.

Your Browser is Special

paul@zpao.com (Paul O’Shannessy) — Mon, 23 Mar 2009 00:03:52 GMT

Roughly 6% of the people visiting this site in the past month were using IE6. That’s mostly insignificant, but I despise IE6 and had to do my part to put an end to it. So, following in the footsteps of The Rissington Podcast (and surely others), I’m serving up an IE6 stylesheet complete with Comic Sans. I also put together a super tiny script that puts a special message up top.

I’d been wanting to do this for a while, but it’s finally done. I’m using conditional comments to differentiate browsers. I used JavaScript to display the message so I wouldn’t be adding clutter to my source, even if nobody else would see it. View the source if you’re interested.

And yes, I’m biased about the browser I’m suggesting, but I’m allowed to be.