With the rush of new browser versions in the last couple of months, I had to refresh myself on two options that I commonly need.  I thought it would be nice to put the methods to do these tasks in the most recent browsers all in one location.  Enjoy!

Resetting Internet cache

Browser “cache” or “temporary Internet files” are your browser’s way of saving you time by not downloading web pages and graphics again that you have already seen. However, in my world of web development, being able to reset your Internet browser cache quickly is very important. When we make even the smallest change to a page or graphic, it almost always requires a complete page refresh by the client.

Google Chrome (Version 16)

1. Click the wrench icon on the browser toolbar.
2. Select Tools.
3. Select Clear browsing data.
4. In the dialog that appears, select the check-boxes for the types of information that you want to remove. Usually you only want “Empty the cache“!
5. Use the menu at the top to select the amount of data that you want to delete. Select beginning of time to delete everything.
6. Click Clear browsing data.

Internet Explorer (Version 9.0)

1. Click the Tools button, and then click Internet options.
2. Click the General tab, and then, under Browsing history, click Delete.
3. In the Delete Browsing History dialog box, select Temporary Internet files ONLY, click Delete, and then click OK.

Firefox (Version 9.0)

1. At the top of the Firefox window, click on the Firefox button (Tools menu in Windows XP) and then click Options
2. Select the Advanced panel.
3. Click on the Network tab.
4. In the Offline Storage section, click Clear Now.
5. Click OK to close the Options window

Show the menu bar

I guess I’m old fashioned, but I really like to have the “File, Edit, View, Favorites, Tools, Help” menu options at the top of each of my browsers, even if it does take up a little bit more vertical space of my monitor. The newest browsers make this setting pretty hard (and in Chrome’s case – impossible!) to find, so here’s the instructions:

Google Chrome (Version 16)

As far as I can tell, there is no menu bar in Chrome! Shocker! All user activities are located under the “wrench” icon in the top right cornder instead (supposedly).  Please comment below if you’ve found an add-in or work around!

Firefox (Version 9.0)

If you’re using Windows 7 or Windows Vista, you now have an orange Firefox button that takes the most common functions and puts them in one menu.

• To temporarily show the old style menus, just press the Alt key.
• To have them shown all the time, right-click on an empty section of the Tab Strip and check Menu Bar in the pop-up menu.

Internet Explorer (Version 9.0)

The menu bar can be turned on or off in Windows Internet Explorer. Here’s how to display it:

1. Open Internet Explorer by clicking the Start button . In the search box, typeInternet Explorer, and then, in the list of results, click Internet Explorer.
2. Press the Alt key.

This headline jumped out at me today as I was browsing the web for new blog ideas:  The End of an Era: Internet Explorer Drops Below 50 Percent of Web Usage.  For years I was a fanatical and defiant IE user– perhaps it was the old MSCE loyalty in me– but eventually I went to the dark side and started using Firefox.

What was interesting to me about this article was actually not necessarily that IE continued to slide in popularity (duh), but that Chrome overtook Firefox (at least in that site’s stats).  The article’s claim that Chrome is now “the technologist’s browser of choice” is certainly food for thought.  Though I reviewed Google Chrome several years ago, soon after its release, I didn’t see a significant advantage versus the browsers I was already using and few of my clients were using it.

However, Beacon’s web developer’s often share their preferences for Google Chrome for its speed and performance and I’ve finally made the jump to Chrome as well.  I find that it is consistently faster and less buggy that other browsers, but what ultimately put me over the edge was an issue with AspDotNetStorefront’s HTML editor and newer browsers.  I administer many AspDotNetStorefront sites and simply couldn’t wait for an upgrade to 8.1 or 9.2ML to use the WYSIWYG editor in admin.  Since the editor continued to work in Chrome, I guess I’ve officially made the switch! Who’s with me??

We recently launched the Beacon site with a new design which included a handful of jQuery animation, many of which had replaced the the previous design’s Flash-intensive content. We have recently come across an issue with the jQuery library with some builds of IE7 and IE8 that resulted in an extensive trail of debugging. We concluded that it was a browser issue (even in different OS environments) that was only fixed by re-installing IE. Here I will outline the issue and the debug trail–and hopefully maybe even think up some potential fixes that weren’t explored when testing was originally performed.

The Issue

In IE7 and IE8 we found that refreshing the homepage would crash IE and sometimes handle restoring the tab, other times not.  Microsoft has acknowledged this error in an KB article.

Error Screenshots

Initial view of most common error displayed.	Error message that would periodically show right before the tab recovers.
Details of error.	Advanced error detail screen.
When tab is not recovered, this screen is shown. Had to repeatedly refresh until this error occurs.	Just-In-Time Debugger error found from a different machine.

The Debug Trail

• Initial replication of issue in IE 8.0.6012 on one of the test machines using a Windows XP environment.
• Attempted browser-configuration changes that might’ve caused issues including:
• Privacy Settings
• Security Settings
• PrivateBrowsing
• Add-Ons disabled
• Just-In-Time Debugging (picked up from a slightly different error that was sent to me as a screenshot from Mark Dirks — last one on right shown above) Unfortunately not of these seemed to be the culprit.
• Disabled JavaScript in IE altogether–which of course fixes it but not what we we’re aiming for. This confirms it is a JavaScript/jQuery related issue
• Attempted using different versions from currently used (1.6.1) to most recently published version from jQuery site (1.6.4) – tried both compressed/uncompressed versions without any success.
• Checked a  changelog of jQuery since version 1.6.1 onward for IE7/8 errors. *Anything related to these browsers I had checked out scripts for any instances of (CSS background-image in jQuery and other function calls)
• One Google search led me to a site that reported changing the jQuery file name had corrected their similar mshtml.dll error—-not the case here)
• Double checked the in-line JavaScript as well as .JS file functions dependent on the jQuery library contained no redirects or any instance of the window.location method Since the IE8 error that comes up sometimes on the test machine says the browser attempted to load more than twice) – the only instance of this I found is a comparison checking if ‘#beacon-video’ is in the URL and if so, it runs a function to scroll the Beacon video into view and sets the tabs display(css) values. The window.location value is never assigned anywhere.
• Checked that there weren’t multiple instances of window.onload or jQuery(document).ready()
• Ran the jQuery library file through a beautifier to get a better look at the pin-pointed trouble spot you found and checked for any obvious issues. Justin Klingman found that in the compressed library he could comment out the last half of the code which removed the crash so before ‘beautifying’ the code I had marked this position with a comment and looked in the region after the code was cleaned up.
• Removed all other scripts from the page to see if those dependencies may have had an impact on the crash, but removing them all (including the JavaScript function calls in the body,) except for the jQuery Library. No difference, same crashing effect.
• The only change that did successfully fixed the crashing tab to load was removing jQuery from the page, however, when the content of another root level page (the SEM pages) into the root default document, that loads/refreshes fine without crashing. The only difference between interior/homepage in terms of JavaScript is the presence of the homeScripts.js file and the inline function calls on the homepage. After further testing this, removing only homeScripts.js still crashed the tab on the homepage (unless jQuery was also removed) — All internal pages use the same copy of the jQuery Library and they don’t crash, so the exact source of what’s crashing the page/tab is still not clear to me.

I’ve finally done it… No one I work with ever thought it would happen and they are actually waiting for the coming of the apocalypse this afternoon.  I, the Microsoft Certified Systems Engineer and over-all long-time Microsoft geek, have finally abandoned Internet Explorer.  This has been a very long time in coming… I’ve fought the tide for years around here– one of the very last to cling to IE in an office full of Firefox and Chrome crazies.

Why now?  Up to this point, my argument has always been that when my clients converted, so would I.  As a web site project manager, I felt I need to see my client’s web sites as they see them, using the most popular Internet browser and version.  For that reason, I’ve kept my eye on w3school’s browser statistics for the point at which Internet Explorer would be overtaken in the market.

The dominance of IE has steadily declined every month since January of 2006 and in late 2008 began to be overtaken by browsers like Firefox, Chrome, Safari and Opera. By May 2010, the combined total of all versions of IE held only a 32% market share, versus Firefox’s 46.90% and Chrome’s rapidly accelerating 14.5%.  That tells me that most of my clients (and their customers) are now looking at their web site in something other than IE.

In addition to the stats, IE’s poor performance has finally put me over the edge.  I have a slightly aged Windows XP machine and with every Windows security update (are they coming hourly now??), IE gets more and more painfully slow.  Pages hang, script errors everywhere, terrible response time…  I suppose that some of this is due to developers (from companies OTHER than Beacon!) not testing their new sites in IE as well as they should (shame on you!).

Finally, the add-ons and utilities being written for Firefox and Chrome these days are simply unmatched.  See one of my colleague’s list of great web tools for Firefox.  Our developers used these extensively, and I can’t wait to start putting them to use myself.

So there you go, the day that I never thought I’d see has finally arrived.  Now, with all this said, you can count on me and the others a Beacon to carefully test your new web site for cross-browser compliance in all nine (yikes!) popular browsers/versions, but for my own personal use, it is Firefox for me– that is until Chrome takes over of course.  Now that I’m playing the field, may as well be open to everything!