The first image shows a screenshot of the problem: the title of the post is drooping into the post. Usually when you see something like this, it means that the containing element has not been cleared. There are a number of ways to clear an element: a popular fix these days uses a pseudo class; the classic approach has been to put a cleared element within the same element as the floating element, but after it. Neither fix works for this bug.

Thankfully, I found a demonstration of a similar problem with IE 7. Apparently if the element containing the floating element has a set height or a maximum height, it confuses IE 7. According to the standard, a browser should obey the CSS height of the element (and IE 7 does—good job!—unlike IE 6). But every cleared element after the floater should be pushed down, not overlapped, by the floater.

The solution is to remove the height assignment from the container element, if you can. In my case, for another part of the site experiencing the same problem, I needed the element to have enough height to show a background image. The solution was to use the min-height property, which doesn’t trigger the bug.

The final image shows what it should look like, as rendered by Firefox.

Yesterday I upgraded my main computer from Kubuntu 5.10 (Breezy Badger) to 6.06 (Dapper). It’s probably one of the most painless upgrades of any that I’ve done: I few lines changed and typed, and apt-get does it all.

I’d even say Kubuntu (or Ubuntu) was so easy to upgrade that it’s almost ready to rival Windows or Mac for usability, except for one step: something about the upgrade shot my Nvidia graphics drivers, meaning I had to SSH into the computer and reinstall them. No big deal, but not something I picture the average user being happy about.

There seems to be better sound support in this latest version. Firefox and Flash on K/Ubuntu are known to have sound problems, but adapting this fix to my 32-bit-Firefox-on-64-bit-Linux-setup, I added a file named “firefoxrc” with just one line (FIREFOX_DSP="aoss") to /usr/local/firefox32, forcing Firefox to use the ALSA sound server. Setting the system sound server to ESD allows me to avoid the usual conflicts between the Flash and system sounds.

One cool feature of this version of KDE is 3-D representation of desktop switching, pictured. Not really that useful, but fun to play with.

First of all, I wanted to use yum so I could avoid all dependency issues (not to mention it makes everything really easy). So that yum would know where to look for 32-bit Firefox distributions, I added a file named fedora-base-i386.repo in the /etc/yum.repos.d/ directory, including this text (thanks to this forum for the mostly correct info):

[base-i386]
name=base-i386
baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/4/i386/os/
gpgcheck=1
enabled=0

Having already un-installed my 64-bit Firefox, I ran the yum install for the 32-bit Firefox like so:
yum --enablerepo=base-i386 install firefox.i386
and Firefox 32-bit was installed.

One remaining problem were the old Firefox extensions in the .mozilla/firefox/.../extensions/ directory, but I just moved them all into another folder.

Next, I downloaded Flash 7, extracted the file and ran the installer only to get the error message that Flash wouldn’t work with 64-bit architecture.

Here I found the suggestion to change the Flash installation file (flashplayer-installer) so that it doesn’t look for i386 architecture. Under the commented line “# check architecture” in the flashplayer-installer file, I changed i[3456]86) to x86_64), and it worked perfectly.

Missing most Flash-designed sites was no great loss, but now I can visit Homestar Runner and YouTube. And there’s no noticeable performance loss in using 32-bit Firefox instead of the 64-bit.

Now that Firefox has become the first viable contender to Microsoft Internet Explorer in years, its popularity has brought with it some unwanted attention. Last week’s premature disclosure of a zero-day Firefox exploit came a few weeks after a zero-day exploit for Internet Explorer appeared on the Internet. Firefox not only has more vulnerabilities per month than Internet Explorer, but it is now surpassing Internet Explorer for the number of exploits available for public download in recent months

Ou presents two charts showing that in the last seven months Firefox has had 40 vulnerabilities to Internet Explorer’s 10 and 11 exploits to IE’s 6.

As you can see, the facade that Firefox is the cure to the Internet Explorer security blues is quickly fading. It just goes to prove that any popular software worth hacking that has security vulnerabilities will eventually have to deal with live working exploits. Firefox mostly managed to stay under the radar from hackers before April of 2005. Since that time, new exploits are being released almost on a monthly basis.

I don’t think it makes me rabidly pro-Firefox to suggest that there are some good reasons to take these numbers with a grain of salt.

• For one, Firefox was officially released only in 2004, whereas Internet Explorer 6 has been around since 2001 (and that’s not counting previous versions). That’s given everyone a lot more time to find and patch major IE problems.
• Furthermore, Firefox’s open source makes it easier to find and fix vulnerabilities than IE, so in the long run it should be less open to attack.
• Also, according to the Secunia vulnerability reports to which Ou links, the severity of the Firefox vulnerabilities has been less than those of IE. During the same period of time, 14% of Secunia advisories regarding IE were rated “Extremely” critical, but none of the Firefox advisories were. Indeed, 77% of Firefox advisories were only “Moderately” to “Not” critical, compared to only 56% of IE advisories.
• According to the Secunia charts, twice the percentage of IE advisories have gone unpatched compared to those of Firefox.

The problem

It’s not just me

The solution

1. Find your Firefox profile folder, the place where Firefox keeps your personal settings. The path to your profile folder:

   • On Windows XP/2000, the path is usually %AppData%\Mozilla\Firefox\Profiles\xxxxxxxx.default\, where xxxxxxxx is a random string of 8 characters. Just browse to C:\Documents and Settings\[User Name]\Application Data\Mozilla\Firefox\Profiles\ and the rest should be obvious.
   • On Windows 95/98/Me, the path is usually C:\WINDOWS\Application Data\Mozilla\Firefox\Profiles\xxxxxxxx.default\
   • On Linux, the path is usually ~/.mozilla/firefox/xxxxxxxx.default/
   • On Mac OS X, the path is usually ~/Library/Application Support/Firefox/Profiles/xxxxxxxx.default/

   Another easy way to find this folder is to search for the file “bookmarks.html” because your Firefox bookmarks hide out in that folder, too.
2. See if there’s a file in your profile folder named “user.js”. We need to add the two lines in step 3 to that file. The user.js file probably doesn’t exist, but if it does, edit the file using a text editor, such as Window’s “notepad.” Most likely, you’ll need to create the file named “user.js” yourself. That’s easy, too. Copy the text in step 3 into a text editor (such as notepad) and save it as “user” (without the quotation marks). Close your text editor and rename the file (usually you can do that by right-clicking on the file) to “user.js” (again without the quotation marks). Windows will alert you that you’re changing the file’s extension (“It may become unusable”), but click “OK” or “yes” anyway.
3. Either add these two lines to the existing user.js file or create a user.js file for them:

   // Reveal more tab/window options: user_pref(“browser.tabs.showSingleWindowModePrefs”, true);

4. Cut and paste the user.js file into your profile folder (if it’s not already there), close and reopen Firefox, and you’re all set.