Pixelastic

The new Firefox cycle version is such that you might lose all your beloved plugins on each new release.

Fortunatly, most of the plugins still work even when the version updates, so you can still use them.

The easiest way to automatically enable them all is to update a boolean value in about:config that will tell Firefox to not disable older plugins.

The key changes for each version, but is called extensions.checkCompatibility.X.Y where X and Y are the version number (like X=7 and Y=0 for the 7.0 release).

Create the key (as a boolean value), and set it to false.

Here are some quick notes on various browser caching behavior. I was fiddling with Wireshark to optimise my caching strategy and found some quirks one should be aware of.

First, let's define some reload vocabulary.

• initial load is the first time the page is loaded, when the cache is empty.
• hard reload is the classical reload. Clicking the Reload icon, or pressing Ctrl+R / F5.
• link reload is when the page is loaded again after you click on a link to it
• soft reload will be loading the page again by pressing enter in the address bar
• navigational reload is the reloading of a page that occurs while using the previous/next buttons.

For the rest of this blog post, we will assume an HTML page loading the same .jpg file multiple times and the same swf file multiple times too (we will use both IE specific and general swf markup).

The html itself is not cached.

Also, all those static assets will have a Cache-Control:max-age=29030400 header.

All the network tests have been made using Wireshark.

Chrome

Initial load : Download of jpg and swf once each. Perfect.

Link reload & navigational reload: Nor jpg nor swf is loaded again. Perfect.

Soft reload & hard reload : The jpg is downloaded again but not the swf. Chrome sends a Cache-Control:max-age=0 header to the jpg request, to force loading it again.

Reloading images is a standard behavior on images, but I wouldn't have expected it on soft reloads.

Safari 5 Win

Safari behaves much like Chrome, with one important difference. It does not cache swf files at all.

Initial load : The jpg gets downloaded perfectly, but the swf gets downloaded multiple times, one per instance.

Link reload & navigational reload : The jpg is correctly fetched from cache, but the swf are all downloaded again. No swf is ever cached.

Soft reload & hard reload : Much as Chrome, Safari forces the reload of the jpg here. As you might guess, it also reload all the swf too, multiple times.

It means that Safari 5 does not cache any swf file at all. That's pretty impressive.

This same caching bug is talked about on this other blog. I've also tried including flash files from within another flash file (much like the Satay method). The results are the same : no swf flash is ever cached, even in the same html request.

It is supposed to have been fixed in Safari Mac (anyone can confirm this? I don't own a Mac) but the issue is still here on Safari Windows.

IE6, IE7 and IE8

IE6, IE7 and IE8 behaves the same here. They have a less severe version of the bug than Safari 5. At the time of writing I didn't have IE9 to test on it.

Initial load : Same bug as Safari here. The swf are downloaded multiple times, once for each instance. The jpg is only download once.

Link reload, navigational reload and soft reload : This time, everything is fetched from the cache. Actually, even the html is seems fetched from cache (I didn't investigate that much)

Hard reload : Html and jpg are fetched from the server, swf file stays in the cache.

It appears that (surprisingly) IE behaves quite well. Its caching behavior is more aggressive than the others (soft reload is really soft). However, it still have a nasty side effect of loading swf files multiple times on the same page. Shouldn't happen a lot in the real world, but still nice to know.

Firefox 4.0

Initial load : No issue arising. It does fetch each resource once.

Link reload, navigational reload and soft reload : Fetches everything from cache, nice.

Hard reload : Re-request jpg and swf files by adding a Cache-Control: max-age=0 request header. This feels like the expected behavior.

As a security reason, Firefox do not allow an @font-face rule to load fonts hosted on a different domain (even a subdomain).

I don't exactly understand why, I guess it has something to do with preventing crosslinking and copyright violation. I think we should keep the website author handle all this stuff and not required the browser to make assumptions like that.

Anyway, I recently tried to move my CSS file to a subdomain, to reduce pages loading times. Doing so I saw that my fonts did not correctly load on Firefox.

After some digging, I found that I had to manually allow them to be linked from an other domain, server-side. Here is the little snippet I added to my .htaccess

<FilesMatch "\.(ttf|otf|woff)$">
	<IfModule mod_headers.c>
		Header set Access-Control-Allow-Origin "*"
	</IfModule>
</FilesMatch>

Firefox can be quite a pain sometimes. I usually praise this browser features but today I had to deal with one tricky 'intelligent' feature.

You know that autocomplete/autofill feature, so that when you enter your user name, Firefox automatically fill the corresponding password field so you won't have to do it ?

Well, it is bad, and here's why.

How does it work ?

I haven't read the source code, but from what I've experienced it seems to work like that :

For each password field, FF will find the related username text field. This is just a very basic search, it assume that the closest previous text field is the related one. Now, everytime you enter a value in the text field that match one of the username saved, it will autofill the password field.

Note that if you have more than 5 password fields on a page, the feature will be disabled.

What is terribly wrong with this approach

Let's imagine you are a registered user of a website. You want to update your preferences. You have a nice page with lots of input fields where you can change your email, password and date of birth.

For security reasons, your password is not displayed. For convenient reasons, the website also don't ask you to type your password everytime your want to update your settings. It assumes that if you let the password field blank, it means that you don't want to change it. And if you really want to change it, then it asks for a confirmation, to make sure your correctly typed it.

So, with this autocomplete feature, if your email is also your login for the website (as it is often the case), Firefox will autofill the password field with your password. Meaning that if you submit your form, you'll be met with an error because your password and it's confirmation does not match.

You'll then have to manually clear the content of the password field everytime your want to edit your profile. Which is counter-intuitive. The whole convenient method of not changing the password if left empty is rendered useless.

The worst part is that most users won't understand when the error comes and will blame the webdeveloper.

Solutions that does not work

First, Firefox is just doing a very wild guess on that fields. And, there is no way to disable this feature from the page markup. Sure, as a user you can disable it in your browser setting, but as a web developper, you can't disable it.

There is a non-standard autocomplete="off" argument, but it does not work in our case. It is supposed to prevent the browser to store previously entered values on sensible fields (like credit card numbers).

I've tried putting this autocomplete attribute on every input field, even on the form itself. Setting the value attribute does not work either. Even updating the value through Javascript would not work because the password field will get re-populated on every blur event on the text field.

A solution that does work

The final solution I've found is to add a dummy password field between your real mail and password fields. That way, Firefox will autocomplete this dummy password instead of the real one.

Unfortunatly this adds clutter to your markup, but with a little display:none in CSS it won't ever be seen by your users.

When you login in an app and tell Firefox to remember your password, it will then automatically fill any password field that have a login field near it.

It can be quite embarassing when you are developping an admin panel where you can edit your own profile informations. The password field will be filled every time you go to that page, even if you explicitly set no value.

The way to circumvent this is to add an autocomplete="off" attribute to the field.

It may not validate, but is understood both by IE and FF AFAIK.

Whenever you upgrade your Firefox, the new version will overwrite the previous one. If you want to open multiple Firefox versions side by side, here's my way :

• First, uninstall all your previous Firefox installation(s). Make sure to backup any important data beforehand (I personnaly use MozBackup to do that).
• Then install the latest available stable version. This will be the main Firefox version, the one you'll be using on your dayjob and the one you'll always update.
• Now run the Firefox ProfileManager.
  To do that, create a shortcut to your firefox.exe file, then edit this shortcut. In the "Target" field, add -Profilemanager.
  My field looks like : "C:\Program Files\Internet\Firefox\firefox.exe" -Profilemanager
• You now have to create one new profile for each FF version you plan on testing. Give them meaningful names. I named mine "FF3.0".
• Now download the corresponding Firefox version from oldversion.com
• Do not install it, but extract its content (using a archiving tool like winrar or 7-zip) in a tmp directory. Remove the optional directory as well as removed-files.log and setup.exe.
• Copy the content of localized/ into nonlocalized/ (overwrite files if asked).
• You can now rename the nonlocalized/ directory and move it around on your hard drive.
  I renamed mine to Firefox 3.0/ and put it alongside the main Firefox, in C:\Program Files\Internet\Firefox 3.0\
• Create a shortcut to the firefox.exe file in this directory and edit the target field.
  This time, we have to specify which profile to use. Just add -P "FF3.0" -no-remote in the target field.
  Mine now looks like C:\Program Files\Internet\Firefox 3.0\firefox.exe" -P "FF3.0" -no-remote

That's it.
Now, just run your classic Firefox shortcut to open the most up to date Firefox version, and use the custom shortcuts to open previous versions.

I personnaly also rename the different firefox.exe to firefox30.exe, or firefox35.exe to more easily spot them in the taskmanager.

I also edit each .exe with ResHack to change their taskbar icons. I haven't yet managed to change their title.

Edit : Now I can't open .html files directly from the explorer nor follow links from my IM. I still don't know exactly what of the steps above caused that.

I'm French, live in France, but usually prefer having my software in English.

This is so because english words are generally shorter (and thus fits more easily in a GUI) and most of the time french translations aren't optimal.

I just download the latest Firefox version from their website, and without knowing it, it was a French localized one. They do some sniffing on the user agent string and automatically download the corresponding file.

That seems a great idea, but I prefer my software in english, so I searched for a en-US.xpi file to update firefox. It does exists for any other language, but not for en-US, this being the default language, as stated in this bug report.

It seems the only way to have an english Firefox is to download the english version, there is no way to change it afterwards.

You can type about:config and change the general.useragent.locale value to en-US but it does not update the main language, only tell plugins to use that language (AFAIK).

Changing the language in the options only change the user agent string.

Well, I had to backup my profiles, uninstall FF, download the english version and reinstall it.

You probably already have installed on your computer various web browsers (FF, IE, Safari, Opera and Chrome) to test your websites. You most certainly also have multiple installs of IE (or are using IETester) because the underlying engine of those browser is very different from one version to another.

Firefox, Safari, Opera and Chrome users are more educated to the "always update to latest version" paradygm so you rarely have to debug old and obscure version of those browsers.

At least it was what I thought until I was stucked with an old 3.0 version of Firefox on my laptop (mostly due to my inability to upgrade to the latest version. I'm still new to the linux world and my laptop is running ubuntu). Anyway, it made me understand that even if you are willing to upgrade you can't always do it and old browser versions should be supported too.

In a recent CSS experiment, I managed to style checkboxes and radio buttons in pure CSS. Unfortunatly, because I was using some "advanced" CSS selectors, FF3.0 wasn't able to render it correctly, in fact it was able to render only half the rules, making the whole thing totally unusable.

That was a perfect example of an old browser I had to debug. I will not dive into the details of the CSS (mostly because I haven't fixed it completly), and this post was only to remind you (and me) to always check on previous browser versions.

Next post will be explaining how to test on multiple Firefox versions side by side.

You probably already have installed on your computer various web browsers (FF, IE, Safari, Opera and Chrome) to test your websites. You most certainly also have multiple installs of IE (or are using IETester) because the underlying engine of those browser is very different from one version to another.

Firefox, Safari, Opera and Chrome users are more educated to the "always update to latest version" paradygm so you rarely have to debug old and obscure version of those browsers.

At least it was what I thought until I was stucked with an old 3.0 version of Firefox on my laptop (mostly due to my inability to upgrade to the latest version. I'm still new to the linux world and my laptop is running ubuntu). Anyway, it made me understand that even if you are willing to upgrade you can't always do it and old browser versions should be supported too.

In a recent CSS experiment, I managed to style checkboxes and radio buttons in pure CSS. Unfortunatly, because I was using some "advanced" CSS selectors, FF3.0 wasn't able to render it correctly, in fact it was able to render only half the rules, making the whole thing totally unusable.

That was a perfect example of an old browser I had to debug. I will not dive into the details of the CSS (mostly because I haven't fixed it completly), and this post was only to remind you (and me) to always check on previous browser versions.

Next post will be explaining how to test on multiple Firefox versions side by side.

The HTML blockquote element can accept a cite attribute that is supposed to hold the value of the source URI of the quote.

Browsers behave differently when getting this attribute in javascript. Opera and Firefox automatically treat it as a URL, prepending the current domain host if none is defined and encoding special characters.

Safari and Chrome on the other end just return the value as it is present in the HTML.