Archive for the 'Mozilla' Category

Crashtests

Thursday, December 27th, 2007

Crashtest is Mozilla's newest test suite. It provides a very simple way to make sure a page doesn't cause Gecko to crash (or hang or assert or leak). Since I report a lot of crash and assertion and leak bugs, I've been looking forward to being able to use this test suite. (For some bugs, I had been using "== about:blank" and "!= about:blank" reftests, but most of my bugs weren't getting tests checked in at all.)

I spent most of last week making crashtests for old bugs I had reported and checking them in.

So far, these crashtests have found bug 409150, a crash on Windows that happens on Tinderbox but not dveditz's computer, and bug 408746, a crash on Linux that happens on sayrer's computer but not on Tinderbox. They also found a problem in a patch before it was checked in.

The value of crashtests (and reftests) goes beyond keeping regressions out of nightlies. The test suites can be run under Valgrind's Memcheck, potentially finding subtle memory safety bugs that don't normally show up as crashes. The pages can even be used outside of the normal test framework, for example for finding inconsistent-rendering bugs.

Fixing leaks

Thursday, December 27th, 2007

Lately, I've been running debug builds of Firefox with trace-refcnt summaries enabled and reporting any leaks I can reproduce. Frequently, someone else quickly attaches a patch, but in the case of bug 401393, nobody else could reproduce the leak I was seeing. For me, simply loading a page with Flash and scrolling down could leak several objects.

Boris helped me use more detailed trace-refcnt logging options to figure out what caused the leak, and then Jonas assigned the bug to me:

Jesse, here's your first blocker :)

Let me know if you need help and I'll do my best.

I was able to fix the leak, although I still don't understand much of the code for the class I modified. Boris and I also figured out why not everyone could reproduce the leak: it only happened because I was using Greasemonkey, which implements nsIContentPolicy using JavaScript. (Adblock Plus does the same, and it is apparently the most popular Firefox extension, so I'm glad this leak is fixed!)

Knowing how to debug leaks with trace-refcount logging turned out to be useful: I was able to fix a few editor leaks and debug another.

Mozilla 2 thread

Wednesday, December 19th, 2007

There's an interesting thread on mozilla.dev.planning about the scope and schedule of Mozilla 2.

Gecko assertions

Tuesday, November 27th, 2007

Assertions frequently help me find bugs that would be difficult to catch otherwise. I've filed 479 bugs on assertion failures, excluding bugs that also causes crashes or hangs, and 223 of those have already been fixed. (Thanks to Brendan, I can safely file bugs when I see assertion failures, knowing that my bugs aren't invalid.)

Many assertion failures indicate that assumptions were violated in a relatively harmless way, merely causing incorrect layout or slow performance in an edge case. But sometimes they indicate the presence of a bug that could lead to a serious memory safety violation. For example, "ASSERTION: Some objects allocated with AllocateFrame were not freed" in the FrameArena destructor has helped find dozens of bugs that lead to leaks and/or dangling pointers.

Gecko developers have added many useful assertions lately, and it looks like more are on the way. Regression tests for assertions are improving, too.

I have a list of assertions that I ignore during automated testing. Whenever a developer fixes a bug on that list, I remove the bug and the corresponding assertion from the file, so if I hit the assertion again after that point, I'll notice it.

In addition to helping to catch bugs, assertions also serve as "living documentation" about the code's invariants. We notice if they become out of date, unlike Wiki pages and comments. In my dream world, assertions would also serve as waypoints for an automated theorem prover ;)

Geneva’s “fi” ligature

Wednesday, November 21st, 2007

There are good ligatures and bad ligatures, but the “fi” ligature in Geneva is especially bad. This screenshot of Charlie Savage's blog shows Firefox trunk (which supports ligatures) on top and Safari 3 (which does not support ligatures) on the bottom. That thing looks more like a tortured “h” than an “f” followed by an “i”, and it makes it look like the blog's title has only three letters.

A dangerous ambiguity

Wednesday, November 7th, 2007

Brian Krebs recently posted a blog entry, Hiding In Plain Sight, about the continuing problem of executable files disguised as other types of files. Brian explains how to make file extensions visible on Windows XP and wonders why Microsoft didn't make that the default.

But hiding the extension by default is only part of the problem. Most users can't be expected to memorize the meanings of dozens of three-letter filename extensions. Even advanced users can't be expected to check the extension every time they download a 15-second video clip.

The real problem is that the same action -- double-clicking on a downloaded file -- has a completely different meaning depending on whether the file is a document or a program. In the first case, it means "view this document"; in the second case, it means "grant this program all of my privileges".

Mac OS X 10.5 "Leopard" tries an interesting solution: "quarantining" just-downloaded programs. If you download a program using Safari or Firefox, you get a concise dialog reminding you that it was downloaded from the Internet.

Unfortunately, Apple botched an important part of this dialog: the button label. The OS X HIG suggest that button names should be verbs that describe the action performed, so if users only read one word in the dialog, it will be one that differentiates one action from another. (Windows, in contrast, is notorious for using "Yes" and "No" as button labels.) Apple chose the verb "Open", which suffers from exactly the same problem as double-clicking: it has a vastly different meaning for documents and applications!

There is concern that because the dialog is "in the way of what you were doing", many users will click through no matter what the dialog says. So perhaps a better solution is to take a hint from the Web application security model, and grant fewer privileges to most local applications. Why should running a screen saver or local game be so much more dangerous than visiting a web page?

A third possible solution is to make the action to launch an application explicit. In a command-line setting, this action might be "chmod +x". On Mac, a natural choice would be dragging the application to the Applications folder, since that is already a normal part of installing an application.

For now, my workaround is to drag files to VLC (as a habit) instead of double-clicking them. I suggested this in the "Handling downloaded files" section of Security tips for Firefox users.

Mac OS X Ultimate

Thursday, November 1st, 2007

At WWDC in June, Steve Jobs made fun of Vista's pricing and said that there would only be one version of Leopard, at $129. But now we're finding out that only Mac OS X Server may be run virtualized. Since there are plenty of reasons to use virtualization other than for running servers, does this mean that Mac OS X Server is slowly turning into Mac OS X Ultimate?

Slashdot party tonight

Thursday, October 25th, 2007

Slashdot was largely responsible for my initial involvement in the Mozilla project, so I'm looking forward to the Slashdot anniversary party in Palo Alto tonight. Are any other Mozilla people going?