Firefox cache issues

Posted by & filed under Developer Blog.

As a web developer, I am constantly reloading pages that are still in the development stage to see how my code is affecting the outcome (Dreamweaver can only preview so well in the design window, thank goodness for F12). Since I want to be absolutely sure that what I’m seeing is the most current version, I always turn my “Temporary Internet Files” and my “Cache” off. This becomes especially important as I develop with Flash.

When Firefox came out, I went to the options dialogue to turn off the cache and only noticed the option to specify how big the cache could be. So I ignorantly set the size to zero and thought it would do the trick. wrong! This causes major problems with our friend the Firefox.

The first issue I noticed was that I could no longer install extensions and themes. For some reason, firefox has to cache them before it can install them. So, thinking I was a genius, I set the cache limit to 1, instead of zero. That fixed the problem. For the past 6 months (or however long I’ve been using Firefox now) that’s the way it’s been. Until today.

Lately I’ve noticed that my personal websites (including the blog you are reading now) have had problems loading the CSS file. It was kind of random; sometimes it loaded, sometimes it didn’t. I searched and researched the problem blaming Firefox all the way. But today, as part of my research, I upped my cache to 10000 and the problem went away. So I started researching more in that direction and came across a help file on mozilla.org telling me that if I wanted to turn off cache I could do it by plugging about:config into the address bar and changing the setting browser.cache.disk.enable to false.

DUH! Why didn’t I think of that before. Probably because it should be in the options menu to begin with, in my opinion.

Now even though I have my cache set to zero my CSS files are loading properly and extensions have no problems installing because I have actually turned cache “off”.

Backing up Firefox settings, bookmarks, extensions, themes, etc.

Posted by & filed under Developer Blog.

Today I wrote a batch file to back up my Firefox settings. Yesterday, I lost all of my Firefox settings because, like an idiot, I was messing with the application data files without backing them up first. So after re-installing all of my favorite extensions and theme, I decided it was something I never wanted to have happen again. I researched to death a way to transfer this stuff from my laptop (WIN XP) to where the data was lost (WIN 2000), but after a long time I realized that the following file was causing problems:
C:Documents and SettingsprofileApplication DataMozillaFirefoxProfiles
random.defaultchromeoverlayinfobrowsercontentoverlays.rdf
and since I couldn’t figure out a way around it, I gave up. If you know how to deal with it, or why that file causes me problems, I’d love to hear about it.

I also spent a while on google trying to find any type of backup/restore extensions or programs. I did find one called MozBackup, but not only are they not developing it anymore, it didn’t work.

In my research I realized that you can just copy the firefox directory, and use it for backup. So I created a directory called c:documents and settingsprofilemy documentsFFBackupfirefox and a batch script called backupFF.bat in my C:/ root directory with the following code:

xcopy /E /Y “c:documents and settingsprofileapplication datamozillafirefox” “c:documents and settingsprofilemy documentsFFBackupfirefox”

exit

Then I went to control panel > shceduled tasks and created a new schedule to run my bat file once a week. As far as I can tell, problem solved.

Dreamweaver crashes using javascript src in default.html

Posted by & filed under Developer Blog.

One feature of Dreamweaver that I use quite often, is the ability to customize the default code that appears when you create a new document (see http://www.macromedia.com/go/tn_14196). Yesterday I wanted to add a little javascript to the bottom that would allow all of my newly created HTML documents to include the same .js file. Naturally, I added the following code:

<script language="javascript" src="myfile.js"
type="text/javascript"></script>

When I restarted Dreamweaver however, it crashed on startup. I logged off and back into Windows and rebooted the computer thinking something was conflicting with Dreamweaver. I even re-installed Dreamweaver which actually fixed the problem. But then when I copied my old configuration files back to the new setup, it crashed again. I started adding configuration folders one by one and then files one by one until figuring out it was indeed the default.html file causing the problems. I then proceded to mess with my most recent addition—the javascript code.

The code I’ve listed above crashes dreamweaver, but oddly, the following code does not:

<script language="javascript" src=""
type="text/javascript"></script>

Quite frankly, that sucks! I’ve already reported the bug to Macromedia. I guess we’ll see what comes of it.

Embedding Flash While Supporting Standards (and without javaScript)

Posted by & filed under Developer Blog.

An even better improvement to the Flash Satay and Flash Javay methods

I’ve been looking at the Flash Satay method of maintaining valid markup using flash (the <embed> tag commonly used for non-IE browsers is no longer supported by current versions of HTML and XHTML). It always seemed a little wacky and time consuming to have to load your flash content into a container .swf and was not appealing to me at all. The Flash Javay method tries to address this problem, but I never liked the idea of using that much javaScript either. I mean, haven’t we spent the past few years trying to come up with a Flash detection that doesn’t use javaScript? The Javay method seems like a step backward, not forward.

Before I share my newly found solution to both problems, let me share this little newly found secret about Internet Explorer that might be useful to you in many other applications other than embedding Flash. Using the following code will only show up in Internet Explorer browsers:

<!--[if IE]>You are using IE!<![endif]-->

Now that we’ve got that out of the way, lets discuss what I’ve dubbed the Flash Gillay method. (Because everyone who comes up with a modified version of the Satay method has given it a new name, I’ve decided to name this one after myself in hopes for fame and fortune!) The general idea is to use the <object> tag exactly as it is commonly used, but to replace the <embed> tag with the Satay formatted <object> tag. Putting the Satay format inside the common format will work fine for browsers that would otherwise need the <embed> tag without any other code to help it out. For example, the following code will work in FireFox/Mozilla/Netscape without any problems:

<object

classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"

codebase="http://download.macromedia.com

/pub/shockwave/cabs/flash/swflash.cab#version=6,0,0,0"

width="400" height="300" id="movie" align="">

<param name="movie" value="movie.swf" />

<object type="application/x-shockwave-flash"

data="movie.swf" width="400" height="300">

</object>

</object>

Notice that there’s no need for a container movie.

Now of course, IE browsers are going to CHOKE on this trying endlessly to load the second object. Here’s where the above mentioned trick comes in handy. Without using any Javascript at all, we can hide the second object from IE browsers by using the following:

<object

classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"

codebase="http://download.macromedia.com

/pub/shockwave/cabs/flash/swflash.cab#version=6,0,0,0"

width="400" height="300" id="movie" align="">

<param name="movie" value="movie.swf" />

<!--[if !IE]> <-->

<object type="application/x-shockwave-flash"

data="movie.swf" width="400" height="300">

</object>

<!--> <![endif]-->

</object>

And as for the need for an alternate image or text to appear if Flash is not installed, you can now take it a step further and be even more standards compliant than the Satay method by making your alt text readable by screen readers:

<object

classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"

codebase="http://download.macromedia.com

/pub/shockwave/cabs/flash/swflash.cab#version=6,0,0,0"

width="400" height="300" id="movie" align="">

<param name="movie" value="movie.swf" />

<!--[if !IE]> <-->

<object type="application/x-shockwave-flash"

data="movie.swf" width="400" height="300">
Description of Flash Content for screen readers

</object>

<!--> <![endif]-->

<!--[if IE]>

Description of Flash Content for screen readers

<![endif]-->

</object>

Notice the use of <–> and <!–> to trick non IE browsers into thinking that their respective lines end the comment and continue to render what’s inside the IF statement.

Now you can use the latest recommended Flash detection methods making it un-necessary to have your alt content point to a flash download page.

I have tested this method on IE 6.0, IE 5.5, Firefox 1.0, Mozilla 1.5, Netscape 7.0, Opera 7.1, Safari 1.0.2, IE 5.2 Mac, and yes, even Netscape 4.8. If you see any flaws in this method, I’d love to hear about it via email (I apologize for the lack of commenting capabilities on this blog, I’m still working on it).

This method can be seen in practice at /

(12-21-2004 NOTE: Thanks to Stephen Rider for pointing out to me that about 8 months prior to this blog this method already existed as the Hixie Method. I maintain that I wasn’t aware of the Hixie Method at the original writing of this blog and apologize for the repeat.)

(01-17-2005 NOTE: If you plan to use the SetVariable command, you can still use id=”” for the IE version but you should use name=”” for the other version.)

(02-01-2005 NOTE: Comments are now turned on.)

(05-17-2005 NOTE: For information on why this method is more standards compliant than the Satay method, see the W3C Rules for rendering objects. Also, if IE followed these rules completely, they would not choke on the inner object tag, but only render the outter, and there would be no need for the extra IE only code.)

Internet Explorer Standalone Files

Posted by & filed under Developer Blog.

If you are a web designer, and if you are like me, you probably get frustrated by the fact that you can only install one version of Internet Explorer on your computer at a time and that it’s nearly impossible to test webpages to see how they will look in various older versions of IE. Today I came across a website that offers standalone versions of IE all the way back to 3.0 making it very easy to do some simple testing.

Visit http://www.skyzyx.com/downloads/ and leave your frustrations at the door.