Firefox test page

Firefox gurus, a page demonstrating the Firefox long content bug has been created for your browser fixing pleasure. Kindly visit the test page using Firefox 3.0 and Firefox 3.5 for Windows (and possibly also for Linux). The following defects should be evident:

  • At least half the comments should be cut off by the browser.
  • The footer should be cut off by the browser.
  • The form enabling you to add comments may also be cut off by the browser (or it may be incomplete, or the labels for such things as your name and email address may appear in the wrong location).

View the same page in Safari 3+, Opera 9+, or IE7/8, and compare. In the other browsers, all comments are displayed, the footer is displayed, and the content form is viewable and displays correctly. How often does Firefox compare unfavorably with some of these browsers? Hardly ever. Which is precisely why you want to fix it. (That, and you’d like your users to be able to view all the content on a page, not just some of the content.)

The test page is identical to this 2 July post, with comments frozen as of 9 July 2009, and with the site’s original CSS, which revealed the long content bug in Firefox.

A subsequent 8 July post documents the steps I and two other developers took in order to isolate this bug in Firefox, and the CSS workarounds (suggested by two of the site’s readers) which have since been put in place to cover up for this defect in Firefox. The thread also explains what we changed in the CSS to enable Firefox users to read long content on the site.

The CSS cover-up enables Firefox users to read all the content on long pages, but at a cost: there is a flash of red background during slow load times. And, obviously, it’s better to fix Firefox than to create somewhat flawed CSS workarounds that slightly diminish the experience for all users of the site.

Thanks for your help! Let me and this site’s readers know how we can assist you. And remember, please use the test page (not this page or any other page of the site) to isolate the bug in Firefox.

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]firefox, browser, bug, firefox3, firefox3.5, windows, linux, bugs, buggery, debugging, demo, testpage, mozilla[/tags]

79 thoughts on “Firefox test page

  1. Firefox 3.5 on linux (RHEL5, 32-bit) does not cut off the page, footer, or comments form… instead, a small section far down the page in the comments has all its pixels compressed into a narrow band, with the rest blank (the background color). Very strange behavior. Perhaps this is related to the page being so long?

  2. Firefox 3.5 on linux (RHEL5, 32-bit) does not cut off the page, footer, or comments form

    Are you viewing the test page?

    There should not be a problem with this page in any browser.

    The problem occurs in FF 3.x/Win with long pages filled with content. The test page is a demo of that. This page is merely a link to (and explanation of) the demo page.

  3. The test page works for me with Firefox 3.5 on Windows 7 RC x64.

    Extremely bizarre.

    The original page was cut in half for all Firefox 3.x/Win users.

    The test page is a duplicate of the original page that was cut in half for all Firefox 3.x/Win users.

    Yet so far no one who visits the test page using Firefox 3.x/Win has a problem with it.

    I’m at a loss to understand this. Let’s see how other Firefox 3.x/Win users fare with the test page.

  4. I’m using Firefox 3.5 on Windows XP (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5) and the test page is cut off.

    Interestingly, after you’ve put in your fix I don’t see the orange background flash. I am using the greenish color background though.

    Martin.

  5. Ah, sorry Jeff, I skimmed the article and didn’t see that it should be viewed in Windows. Just booted up ye ole Win XP machine with FF 3.5, and sure enough, the content container is cut off on a comment you made, right under “Is it wrong to assume that everyone has read A Preview”. That is very strange indeed.

  6. Since the bug has to do with the floated #maincontent div being cut off, why not un-float it and just use:

    div#maincontent {
    margin: 0;
    padding: 0 30px;
    width: 490px;
    }

    You then would have to absolutely position the sidebar:

    div#wrapper{
    position:relative;
    }

    div#sidebar {
    position:absolute;
    top:97px;
    right:0;
    margin: 0;
    width: 180px;
    padding: 0 20px 36px 20px;
    font-family: “Helvetica Neue”, Arial, Helvetica, sans-serif;
    }

    I haven’t tested this extensively, but it seems to work…

  7. Firefox 3.0.11/WinXP Pro SP3 (32 bit). Test page is cut off on my side (as I expected).

    As a few users with FF3+/Win7 (32 & 64 bit) report that they don’t see the bug, maybe it’s not present on all versions of Windows?…

  8. Just tried it side-by-side on both Windows 7 and Windows Vista with:

    Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1) Gecko/20090624 Firefox/3.5

    On Vista it definitely cuts off in the same place each time. On Windows 7, not so much. It sometimes chops off the bottom, or goes completely black, or glitchy, but it’s very intermittent. Mostly (about 85% of the time, as a wildly approximate guess) it renders fine, seemingly.

    The Vista machine has an nVidia graphics card, while the machine running Win7 does not. Is anyone seeing this who does not have nVidia graphics?

  9. @Charles:

    I have an ATI card (pretty basic, btw, as it is on a ThinkPad), WinXP SP3, FF 3.0.11. I definitely see the bug on 100% of the test page loads. Hm…

  10. Fails for me in Firefox 3.0.10 on Windows Vista SP1 (32-bit). I get redraw errors below the point of failure when menus overlap the content (ie. the Firefox contextual menu): http://files.getdropbox.com/u/146967/foxy.jpg

    Firefox redraws the orange background if I drag the window off the screen and drag it back.

    Did not notice this error in Firefox 3 on Linux (Ubuntu 9.04).

  11. I am using Windows Vista and Firefox 3.0. The bug is evident. I had this issue a few times before on the web site. I hope they get this bug fixed soon…

  12. Excellent. The bug is evident on most Windows systems running FF 3.0 and 3.5. Great! That means the engineers at Mozilla will be able to work on the bug.

    Since the bug has to do with the floated #maincontent div being cut off, why not un-float it and just use

    @Dan:

    The point of this page isn’t to figure out a CSS workaround for a defect in Firefox. I already have a CSS workaround in place on the main site.

    The point of this page is to help the dedicated and talented engineers at Mozilla isolate and fix a bug in Firefox.

    Once they do that, I can go back to my original CSS (which is better for more people than the workaround). I’m using the workaround only because Firefox is broken with respect to long content. I’m not looking for a different workaround, I’m looking for a Firefox fix.

    But thanks for your creativity!

  13. It’s working fine for me using FF 3.0.11 in Windows 7 as well.

    Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)

  14. When visiting the testpage on a Win Xp / FF 3.5, the bug is indeed present. With Firebug i was able to solve the issue, simply by removing overflow: auto; on #wrapper.

  15. Maybe you’ve tried this, but I simply removed the “overflow:auto” line from your div#wrapper css class and everything magically reappeared on the test page.

    I know it’s a CSS fix and not what you’re looking for. ..just FYI. Thanks for indulging me.

  16. Firefox 3.5 on Windows 7 seems to show the entire page for me as well, although starting from comment #44052 the Grab and Drag extension refuses to drag the page, throwing a javascript exception. In particular the .ownerDocument field of the div becomes null below than point. The extension behaves correctly clicking on the background (the body of the page).

    The same can be achieved using the DOM Inspector, using the “Find a node by clicking on it” button. Clicking on the main content div below comment #44052 will give an exception.

  17. Looking at it again, comment #44052 is located at position x:113 and y:32701, so it probably crosses the 32767 boundary. Programmers will know what this means.

  18. What is the the 32767 boundary? Never heard of it… (I’m not a programmer, though, but designer/CSS coder.) And why it would appear on WinXP but not on Win7?…

  19. Signed 16-bit numbers wrap after 2^15, that is after 32767.

    It works fine for me on Windows 7 too, but the Grab and Drag extension refuses to drag the page after that comment, throwing an exception. The same happens if one uses the DOM Inspector and tries to “Find a node by clicking on it” below comment #44052. Apparently the .ownerDocument property for the div node returns null. Clicking on the background of the page (the body tag) works fine.

  20. Signed 16-bit value wrap after 2^15-1, that is 32767, and go back to -32768.

    The DOM Inspector gives a javascript exception if you try to find-by-click anything below that comment, complaining that the .ownerDocument property for the div is null.

  21. Not really helping the issue, however, I thought you should know it does the flashing organ background and cut-off on FF v2.0.0.20 on windows as well.

  22. Interestingly, I decided to test the page in Camino 1.6.8 on my OSX 10.4 Machine and found the same problem. Comment #44052 gets cut off and the footer is gone.

  23. @Amy:

    Camino is Gecko-based, right? Strange that you’re on MacOS X and you see the bug in Camino. Firefox/WinXP has the problem, but Firefox/Mac — no…

  24. Firefox 3.5 on os x. Yes viewing the /foxy/ test page. I don’t see anything either.

    Can’t see what the form issues are because on the test page it says I’m:
    Logged in as Jeffrey Zeldman. Log out »

  25. @Michel: signed 16-bit integers wrap around after 32767, or 2^15-1.
    I see the entire page on Windows 7, but there are still problems: the DOM Inspector gives a javascript exception if one tries to find-by-click any element after comment #44052, complaining about the .ownerDocument property of the div being null.

  26. I think dreadnaut is onto something there. The page cuts off for me, too, in FF/3.5 WinXP, but interestingly, I notice that when you click and drag down in that last visible comment the selection jumps back up to the top of the page, as if the browser’s wrapped the cursor position.

  27. No issues with the test page on FF3 on 64 bit Ubuntu:
    Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.11) Gecko/2009060309 Ubuntu/9.04 (jaunty) Firefox/3.0.11

    The bug does manifest in FF 3.5 Windows XP SP2 32 bit:
    Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)

  28. I just confirmed what dreadnaut said: it has to do with the size of the #maincontent div. Once it gets larger than 32767px it gets cut off. If #maincontent is 32766px or less it’s fine, but if it’s 32767px or larger it gets cut off. Tested on FF 3.0.11 on Vista.

  29. @Dan:

    Maybe Jeffrey can somehow get in touch with Mozilla engineers… I think that once we know the reason for the bug, it’s like half-fixed, and it looks like we’re approaching this! :)

  30. A bug for this problem was filed years ago, but cannot be fixed at the moment.

    Native widgets use 16-bit coordinates, and the fix would require some serious work on Gecko, which might be completed for the next version of Firefox.

    See comments after #132 in the bug report for more information.

  31. WinXP, FF 3.5, it cuts off at comment #44050 for me. Oddly enough, when I began selecting text from “John said on 5 July 2009 at 2:14 am: e” and dragged the mouse downwards, the browser popped back up to the top of the page, and all was hilighted as if I had been selecting text in the upwards direction. I scrolled back down, and what was hilighted was everything above where I had started.

  32. FYI, in Windows 7 / Firefox 3.5, I can see all the comments, but all links and form elements do not work after your “Is it wrong to assume” comment. By not working, I mean it’s basically frozen. Hovering over links does not change their color or produce their URL in the status bar.

  33. Zooming the text size also changes how much is visible. If you come across another site that displays this problem, at least you might be able to shrink the text a bit to read the entire thing, maybe even get to their comment box to point them to Jeffrey’s css workaround until FF gets fixed.

  34. Interesting. The bug shows up in Camino 1.6.x but the page displays perfectly in the Camino 2.0b3 (1.9.0.11 2009060219)

  35. The page works fine in FF 3.5 in Windows 7 RC x64:

    Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)

    But, it is definitely truncated in FF 3.5 in both Windows XP SP3 32-bit and FF 3.5 in Windows Vista Ultimate 64-bit Edition.

    It seems Windows 7 is the only Windows version immune from it. I can also confirm Matt Lincoln Russell’s observation about the links not working at that particular comment and afterward. I did notice that the links near the bottom of the comments section were not working when I first read the page on July 2, but I just assumed FF was behaving badly. Mind you it was only on that original page and no other pages I was reading.

  36. I’m getting the cut off page on Firefox 2.0.0.20 as well. Running on Windows Vista Business, and alongside other versions of Firefox (but I doubt if that makes a difference).

  37. I actually noticed the problem when I was reading the original post, but didn’t really look into it, though I tried reloading the page 2 or 3 times. Visiting the test page, I that was the exact weirdness that I noticed. I’m running on FF3.5/Vista Home 32 bit. And, I was also hoping that if you could separate comments and trackbacks?

  38. Just got curious about the 32767 limit and fired Firebug on the test page. Firebug reports all dimensions and coordinates without any problem, it seams that the JavaScript engine is using more than 32 bits for numbers, while the rendering engine and DOM Inspector use 32 bit integers (as other people reported that DOM Inspector gives exceptions when trying to inspect elements after the break). I am using Firefox 3.5 with Firebug 1.4b on WindowsXP.

  39. What I’m seeing is a combination of what some other posters have. Win 7 (RC, 64-bit), Firefox 3.5.

    I’m able to see the whole page, and also see the complete form. However, the links are not hovering correctly. Hovering on links actually bring up the title tag from a completely different website. The links don’t work when clicked.

  40. The testpage, /foxy/, WORKSFORME with Firefox 3.0.11 on Debian GNU/Linux.

    Is there any reason why you haven’t simply filed a bug in Mozillas system for such, or voted for the already existing bug in their bug-tracking system?

    Just curious about all the fuss.

  41. @Adam:

    Is there any reason why you haven’t simply filed a bug in Mozillas system for such, or voted for the already existing bug in their bug-tracking system?

    Three reasons:

    1. I haven’t seen the bug myself, I’m only reporting what readers have told me. It will be better if the bug is filed by someone who has actually experienced it on their system. Please feel free to volunteer!

    2. I’m home, recovering from 5.5 hours of surgery which I underwent on Tuesday. I’m forbidden to do anything strenuous. Blogging is something I can practically do in my sleep, having been at it since 1995. But filling out a Mozilla bug form has never worked for me.

    3. Most importantly, a lead Mozilla engineer will be looking directly at this problem, and the test page will enable that engineer to do his job.

    or voted for the already existing bug in their bug-tracking system?

    I’m not sure it’s the same bug.

    If it is the same bug, “voting” for it doesn’t seem like it’s going to fix anything soon.

    By contrast, creating a test page and asking a friend to ask a friend (who happens to be a lead Mozilla developer) to check it out just might get it fixed.

    The current CSS, with its orange background flash drawback, distresses me. The original CSS created a better experience for all users. I long to restore the original CSS, but can’t do so until Firefox is capable of showing long content.

  42. No problem, Jeffrey.

    I have now tested it on my home machine with exactly the same setup (FF3 + Ubuntu 8.04) and can confirm the same behaviour.

  43. Foxy test looks to work (ie. pass) in FF3.5 and Chrome under Windows 7 build 7100.

    I have also seen the bug Paul Decowski has in long content in Google Reader under FF 3.0.11 both Win XP and Ubuntu 9.04

  44. @Jeffrey Zeldman: I think it is great that you’re using your web-rep. to get the bugs that annoy you fixed. And I wish you a speedy recovery. Thanks for the thorough answer.

  45. Hmm.. I’m using Firefox 3.0.11 on Ubuntu Linux 8.10, and I don’t see this truncation bug, so it may only affect windows users.

  46. People have mentioned in a couple comments that it’s cut off after a certain number of pixels, and I’m sure you’re sizing some things in pixels. If you set the dimensions in ems, will it turn into 32767 em instead of 32767 px?

    Maybe you (by which I mean anyone reading this page) could do tests with various elements exceeding 32767 pixels, and set to the offending overflow value.

    Hey, I know a great fix! 7pt pixel font, with lines of text that stretch across the entire screen! Set the leading to a small number, and there you go: You can fit as much text as you can imagine, without ever reaching the pixel limit!

  47. It’s broken in SeaMonkey 2.0a3 (build ID: 20090223135443) and 1.1.17 on Windows XP sp3, too. Not that anybody USES SeaMonkey (there’s like 20 of us), but maybe this will help point out that it’s endemic to the engine and not just Firefox.

  48. The test page breaks near comment 44050 with Fx 3.5 (Shiretoko) running on Ubuntu 9.04 x86_64. When I scroll down from the top of the page I see something like this. However, scrolling up from below the offending area shows no visible anomalies. In my case the footer looks fine, but even though links there and in the comments can be clicked, the text below the offending area cannot be highlighted with the mouse. I’m very scared.

  49. This isn’t specifically about the bug in question, but I have a problem with Firefox 3.5 that I have discovered. I am hoping someone knows what the deal is. For whatever reason, regardless of what fonts families, font sizes, etc. I choose in the CSS, Firefox 3.5 refuses to display it. It has messed up the typography of so many web sites. Instead it displays Times New Roman consistently. Obviously I could go into the options and change this to my desired font, but that will not help the user when viewing the page. Any ideas?

  50. For me, the test page displays all comments, including the comment form.

    I’m using Firefox 3.5 on Windows 7 RC x64.

  51. So, in the end, if you read through all the comments on the original bug (the one that the above bug links to), they’ve fixed it, but only in Gecko trunk 1.92 and that won’t land until Firefox 3.6.x. So current FF 3.0 and 3.5 users will never see a fix for this.

Comments are closed.