Category: bugs

There’s good news and bad news. The good news is that Firefox 3.0 and 3.5 for Windows no longer cut long pages of this site in half, hiding 50% or more of the pages’ content, including the footer, because of a newly discovered bug in Firefox (discovered by this site’s layout).

The bad news is that the price of the “fix” is an annoying flash of reddish-orange background. When you first load a page in any browser, rather than the main content’s off-white background area, you instead see the text against a reddish-orange background, obscuring words (including the drop cap), disrupting user experience, and raising doubts about the professionalism of the site and thus of the opinions it expresses.

With the annoying flash of colored background, everyone who reads this site suffers. But without it, Firefox 3/3.5 cuts long pages in half. Until Firefox fixes the bug, all readers of this site will experience what I’ll label “the Flash of wrongly styled background color.” (Note: although the browser is still broken, the color flash has since been “fixed.” Impatient ones, skip ahead to the 9 July update. Narrative fans, keep reading.)

Here’s the story.

Validators were no help

My 2 July post, XHTML DOA WTF, has thus far received 194 comments. Firefox users told me the thread “died” after comment #44049 in Firefox 3 and 3.5 for Windows. The problem also later surfaced on In Defense of Web Developers, written yesterday morning just prior to my surgery. Let’s stick with the 2 July post, though, which is where we did our Q&A.

W3C and WDG validation services both indicated that there was an error on the page, but neither validator could explain it.

• The W3C showed a long list of unclosed elements (which in fact were closed), a typical W3C validation error when that validator misidentifies the actual problem. The W3C validator has made this mistake since at least 2001. Whenever I complain to the W3C, I’m told they need volunteers to help them fix the validator. So I more often rely on the WDG validation service.
• The WDG validator (usefully and apparently correctly) indicated that a single illegal UTF character in a comment it could not show me was causing the dilemma. This validator gave me a line number, but no code output—making the line number useless, and forcing me to go into my database and examine each of 194 comments visually for unsupported character problems.

In search of a single UTF-16 character

I next spent two hours of an insanely busy pre-surgery day unsuccessfully attempting to manually track down UTF errors in comments that no validation service was able to pointpoint. I had to apologize to colleagues and clients to whom I owed work, since the quest to make my personal site legible and usable to Firefox users took precedence over paying work in my sad little mind. (Call it a mark of the high esteem in which I hold Firefox; also call it a concern for readers.)

Automattic’s designer/developer (and my friend) Noel Jackson then took over for me and was eventually able to locate a single UTF error in a Japanese pingback. Or so it seemed.

WordPress, the power behind this site, is supposed to convert illegal UTF-16 to legal UTF-8, and we thought it had done so. Nevertheless, the only validation service to have claimed anything semi-coherent said otherwise. To solve the problem required brute force: we deleted the entire Japanese comment. To the clients and colleagues to whom I owed work I was unable to finish while tracking down a Firefox bug, I now also owed an apology to a Japanese blogger. Personally, I blamed Firefox for ludicrously Draconian error handling, but at least I thought we had “solved” the needless problem raised by such behavior.

Drudge work for nothing

I owe Firefox an apology. Draconian error handling of impossible-to-trace possible UTF errors was not the cause of its failure to display pages correctly. Inability to parse valid CSS on long pages was the actual cause.

Although my page now validated, Firefox still cut it off at the waist. Thanks to this bug, users of Firefox—many of whom care greatly about web standards (it’s one reason so many developers choose Firefox)—were unable to read more than half the comments about XHTML 2 and HTML 5 from their fellow standardistas. They were also unable to post comments or view the footer (thus making them unable to view other content on this site, as well as third-party site highlighted in the footer). This was a win for nobody, except maybe Microsoft, Opera, and Safari. And, like I said, we like Firefox and people who use it. Back to the drawing board.

Seek and ye shall not find

Nikolay Bachiyski, a lead developer at Automattic, then conducted a series of tests:

1. He established that only Firefox 3.0/3.5 (and only in Windows) cut the valid web page’s content in half.
2. He verified that the page’s content was valid (UTF-8) as was its markup.
3. The DOM loaded properly.
4. There wasn’t an (X)HTML parsing problem.
5. Disabling JavaScript made no difference.
6. Disabling CSS enabled all the page’s content to display in Firefox; turning CSS back on cut the page in half again. Clearly, the issue was with CSS.
7. Nikolay then disabled the lines of Mozilla- and Webkit- oriented CSS3 that generate “warnings” or “errors” in the W3C validation service. But even with those lines disabled and the CSS completely valid, the page’s content failed to display completely in Firefox. The bottom of the page was still cut off.

A CSS “fix” with a drawback

Valid CSS was somehow to “blame” for Firefox’s inability to show a long page without hiding half the content.

You may ask why I didn’t discover this problem during the building and testing of my site’s redesign. You might even ask why my readers didn’t discover it (since I beta tested the redesign at several stages). The answer is simple. I never tested a dummy blog post with nearly 200 comments. It didn’t occur to me that more than 40 comments would be necessary to test whether valid CSS and XHTML would work in good modern browsers, let alone in one as excellent as Firefox.

Michel Bozgounov and Kyle Weems then proposed a simple CSS fix:

div#wrapper {overflow: visible;}

My friend Noel implemented the CSS fix while I was unconscious and having stuff cut out of me.

It works, and I thank all these gentlemen. But it has the unfortunately side-effect of inflicting a flash of reddish-orange background on the page until most or all content has loaded. (I had previously spent over two weeks eliminating that flash of background.) And it does this in all browsers (or nearly all), not just Firefox. To force Firefox to display all content on a page, I have to force every other browser to flash red before it shows content.

Obviously, it’s vital that Firefox users be enabled to read and comment on long or popular posts. But there must be a better way than deforming the CSS. And there is a better way: namely, a Firefox bug fix.

Our friends at WordPress have contacted our friends at Mozilla, so we are hopeful that this will be fast-tracked. Mozilla friends, call on me to help at any time.

9 July Update: 99% solution

With the addition of 1000px of min-height to #wrapper, the reddish-orange flash has been eliminated, at least in pages that load quickly. (On long pages, or with slow connections, the reddish-orange background remains painfully visible until the page finishes loading.) Read more about this CSS adjustment. Note that adding CSS workarounds is not the same thing as fixing browser bugs. (Indeed, CSS workarounds may retard browser development by removing the problem so it never gets fixed.)

A Firefox Test Page

As I am not entirely satisfied with this CSS workaround (despite my gratitude to its authors) and as I do not want Mozilla’s engineering wizards to be unable to fix Firefox because of changes to my CSS, I have posted a Firefox test page using the site’s original (perfectly fine, background-flash-less) CSS, and a page explaining the Firefox test page.—JZ

Read more

• HTML 5: Nav Ambiguity Resolved. An e-mail from Chairman Hickson resolves an ambiguity in the nav element of HTML 5. What does that mean in English? Glad you asked! — 13 July 2009
• Web Standards Secret Sauce: Even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. Thanks largely to the success of the iPhone, Webkit, in the form of Safari, has been a surprising force for good on the web, raising people’s expectations about what a web browser can and should do, and what a web page should look like. — 12 July 2009
• In Defense of Web Developers: Pushing back against the “XHTML is bullshit, man!” crowd’s using the cessation of XHTML 2.0 activity to condescend to—or even childishly glory in the “folly” of—web developers who build with XHTML 1.0, a stable W3C recommendation for nearly ten years, and one that will continue to work indefinitely. — 7 July 2009
• XHTML DOA WTF: The web’s future isn’t what the web’s past cracked it up to be. — 2 July 2009

[tags]browser, bugs, Firefox3, Firefox3.5, Firefox/Windows, browsers, firefoxbugs[/tags]