Crash as crash can

April 7, 2003

As long-time readers might remember, when we first started publishing MacEdition we hit a Netscape 4 crasher bug.

It took ages to work out what the issue was and – not surprisingly – it was a pretty complex set of dependencies that triggered it.

The irony was, the only reason that the DIV in question had a border at all was to work around a different CSS bug in Netscape 4 – to do with the way it draws backgrounds. So I ditched the border and ever since, all Netscape 4 users have been getting a different look for MacEdition than users of standards-compliant browsers. They always have, and so far, no one has complained.

This was an important lesson on the way to a standards-oriented approach to Web design – graceful degradation. There will be even more of that when we roll out a new design – more on that in a future column.

Recently, I’ve been getting more notifications of Netscape 4 crasher bugs from readers. It could be just something in the water, but I suspect it’s more likely to be people’s increasing familiarity with CSS. As designers become more ambitious, they become more likely to hit on new things that hadn’t been tried before, and which trigger bugs that hadn’t been noticed or isolated before. So it seems that as we start to take advantage of the current crop of browsers, we learn just how lacking the older ones really were.

Request for comment

Once you’ve hit on a crasher bug in a browser like Netscape 4, how do you isolate it? Identifying support or lack of support for particular properties is usually pretty straightforward. Unless you’re trying to identify some of the kookier problems in iCab or OmniWeb, it might only be necessary to have a few tests per property-value combination, in the simplest possible contexts.

Crasher bugs, by contrast, are often the product of dependencies – the complex interactions of multiple properties that might well be safe to use on their own. This makes them hard to isolate unless you follow a systematic methodology.

First, validate your markup and stylesheet. Netscape 4 can be pretty forgiving of shoddy markup, but mis-nested or made-up tags can cause crashes. A correspondent to our Feedback Farm once tried to make his name bold by wrapping it in <BOLD>...</BOLD>, which isn’t part of any known version of HTML. For some reason, the code behind the Feedback Farm didn’t strip out the errant tag (it does now!) and so it found its way into the display of this page, causing a crash for certain versions of Netscape 4. So Rule 1 is to validate, validate, validate!

Rule 2 is isolate. Say you have a page that crashes some version of some browser. Comment out (don’t delete!) the whole stylesheet and load the page. You really need to save a local copy of the page to do all this efficiently. Next, start adding back style rule blocks by moving the comment markers, and refresh each time you change something, until you get a crash. Comment out only the offending style rule and see if that causes a crash. You might need to check for dependencies on the presence of other style blocks – comment everything but the style rule block you have identified as causing the crash, and reload again. If that doesn’t cause a crash, it must be the interaction of different styles – perhaps those applying to parent or child elements of the element affected by the errant style block you’ve already identified.

Now, trim. Chop out all the markup except for one example of the crash-causing element, and its direct parents and children. Sometimes, as with the border-style crash that MacEdition encountered, it’s not the rule that’s the problem but that the style rule applies to this element in a particular set of parent elements.

You should now have a minimal page with only those elements necessary to cause the crash, and the style blocks that go with them. The next stage is to trim further: focus on the particular property-value combinations in the rule block that cause the crash. Comment out each one in turn, then put it back and comment out the next. You might find that particular pairs of style rules are the problem, not a single one. There are two known bugs where three particular properties together will cause a crash for Netscape versions before about 4.73, but any two of the styles will be fine.

Explore

The end result of this trimming and isolating should be a truly minimal test page that contains only what is required to trigger the bug. You might be content to stop at this point and notify the appropriate publisher or bug guide compiler (me, for example) about the case you’ve identified. If you have time, though, it might be worth exploring the bug a little further to see if it arises in more than just the circumstances you have struck.

Does it matter if you change units from px to %? If you were using compact notation like margin: 0px 2px, does setting properties individually make a difference? Probe the edges of your test case for alternative examples to the crash you’ve found – or important exceptions to it.

Why this matters

By the time you’ve gotten to this stage, you’ve probably crashed your browser thirty or more times; if you’re on OS 9, you’ll probably want to restart every so often to clear up lingering instabilities in between tests. Is it really worth the effort – especially if the browser in question is some marginal browser or a long-since superseded throwback like Netscape 4? I’d argue that it can be.

Different presentations of a particular layout for a particular browser is one thing – but crashing is hardly graceful degradation. I’m quite willing to allow presentation and styling to differ across browsers if some lack the standards support to handle the styling I prefer.

But it’s not acceptable to have browsers crashing on your content. Of course, they shouldn’t crash on valid markup and stylesheets, but sometimes they do. If possible, one should avoid the situation that causes the crash. This might not always be possible, especially if the browser-OS combination experiencing the crash is sufficiently restricted as to be beyond your testing resources. If, say, only Netscape 4.07 under Windows 98 has a problem, and your PCs are all running Windows ME or later, there’s just not a lot you can do.

But if you have the crashing browser in-house, or you can get it, why not take the time to isolate the bug? If it’s a current browser, you’re much more likely to spur the developers to action with a good test case. And even if it’s an old browser, a good test case is likely to be more useful to your peers.

— CodeBitch (codebitch@macedition.com) is the grumpy cow who does the HTML production for MacEdition. Read other articles by CodeBitch

E-mail this story to a friend