IE7

Recap: In certain situations, jQuery’s $.browser.version will report IE 7 as version 6.

Considering the problem is due to IE 7 having an incorrect user-agent, I'm not sure that this problem was up to jQuery to solve. It would have required the user-agent parsing code to check non-user-agent properties...which is probably a bad idea.

I found out that my original code suggestions might fail in situations where IE 6 is using a 3rd party library to add XMLHttpRequest support, so here are my updated IE 6 and IE 7 detection suggestions:

Override the $.browser.version value:

jQuery.browser.version = jQuery.browser.msie &&
    parseInt(jQuery.browser.version) >= 6 &&
    typeof window['XMLHttpRequest'] == "object" ?
        "7.0" :
        jQuery.browser.version;

Add a new msie6 property:

jQuery.browser.msie6 = jQuery.browser.msie &&
    parseInt(jQuery.browser.version) == 6 &&
    typeof window['XMLHttpRequest'] != "object";

Keep in mind that $.browser is now deprecated, which means it will go away at some point in a future release. I'm not going to get into the object detection vs browser sniffing debate, but just be aware!

Opera 9.5

Recap: Opera, in an effort to follow standards, changed where it was storing the value for the viewport height.

This issue was fixed in jQuery Ticket 3117 by Ariel Flesler. If you have Opera 9.5, you can test the results on this page.

Safari 3 (Windows)

Recap: The following element would not be hidden in Safari: $("<div/>").hide().appendTo('body');

I found out that this issue also occurs in Safari 4! The original jQuery ticket I mentioned was marked as a duplicate, but the issue was fixed in ticket 1239.

Summary

Besides the problems with the IE user-agent, the jQuery developers implemented fixes for the two other browser issues that I had previously blogged about. jQuery 1.3.x has a number of new features and code improvements and continues to be, IMO, the best available JavaScript library.

I tested SimpleModal (tests and demos) with jQuery 1.3 and everything seems to be working as expected. After reading about all of the speed improvements, I thought it would be interesting to run some tests (Firebug 1.3 Profiler) comparing the SimpleModal demos with jQuery 1.2.6 and jQuery 1.3:

I haven't looked into why 1.3 has more calls for the Contact Form, but even so, the execution time (ms) has improved for each one!

Congratulations to the jQuery team and Happy Birthday!

Suppressing the temptation to try out all of the new features, I jumped right in and started surfing the web. I'm actually using Chrome to type up this post and so far, everything seems to be working fine.

So far the only issue I've noticed is the rendering/handling of the LEGEND HTML tag inside the FIELDSET HTML tag. Here is a screenshot of the difference between Firefox (left) and Chrome (right):

Note: The same rendering issue happens in Safari, so I need to determine if it is being caused by Webkit or an error in my code ;)

I was really interested to see if Chrome included any developer tools, similar to Firebug. There is a JavaScript Console which gives you similar information to what you'd get in the Firebug Console, Net and HTML tabs. There is also a JavaScript debugger, but at this point, it looks like it is just a command line tool, so IMO, Firefox with Firebug has a clear advantage in JavaScript debugging.

One new feature I really like is the Task Manager. It's just like the Task Manager in Windows, except for it only displays Chrome related information. It breaks it down the Memory, CPU and Network utilization for the Browser, Tabs, and Plug-ins:

John Resig, Mozilla employee and jQuery creator, recently posted his thoughts on the Task Manager...it certainly seems like a very useful tool.

For an initial release, Google Chrome seems to have a lot of promise. It will be interesting to see how this affects the current browser landscape.

If you've tried Chrome, I'd be interested to hear your first impressions...

Download

Firefox 2
Firefox 3

Install

If you already have one version installed, just install the other version, making sure to choose the Custom installation option. This will allow you to install the files into a different directory.

For example, if you already have Firefox 3 installed in C:\Program Files\Mozilla Firefox, install Firefox 2 in C:\Program Files\Mozilla Firefox 2. The rest of this post assumes that you are installing Firefox 2...modify as necessary.

Manage Profiles

From the command line, run the Profile Manager to manage your Firefox profiles:

"C:\Program Files\Mozilla Firefox 2\firefox.exe" -profilemanager

Create a new Profile, firefox2 for example, and then exit the Profile Manager.

Update Firefox Shortcuts

Mofify the Target value on your shortcuts to Firefox. Right-click on the short-cut and select Properties.

For the Firefox 2 shortcut, on the Shortcut tab, enter:

"C:\Program Files\Mozilla Firefox 2\firefox.exe" -no-remote -p firefox2

Do the same for the Firefox 3 shortcut, with the following:

"C:\Program Files\Mozilla Firefox\firefox.exe" -no-remote -p default

Enjoy

Install Firebug 1.05 for Firefox 2. You should now be able to run both Firefox 2 and 3 simultaneously. If you already have Firefox 2 are installing Firefox 3, just change the paths/profile names mentioned above to fit your situation.

Caution: If you already have one version installed, use the Firefox Profile associated with it, otherwise you might loose your settings.

During the time that I've been using jQuery (about a year now), I've run into three fairly significant browser issues. Between IE, Firefox, Safari, and Opera, Firefox is the only browser that I have yet to experience any issues with (related to jQuery, of course).

IE 7

In certain situations, jQuery's $.browser.version will report IE 7 as version 6. Jamie Thompson noted one possible situation on his blog, but typically the issue is caused due to the fact that some copies of IE 7 included MSIE 6.0 within its user-agent string.

There is a jQuery Ticket open for the issue, but a solution has not been chosen. Based on some ideas that Jamie had, I came up with a possible solution by overriding the $.browser.version value:

jQuery.browser.version = jQuery.browser.msie &&
    parseInt(jQuery.browser.version) >= 6 &&
    window["XMLHttpRequest"] ?
        "7.0" :
        jQuery.browser.version;

Additionally, there are situations when I'm just looking for IE 6:

jQuery.browser.msie6 = jQuery.browser.msie &&
    parseInt(jQuery.browser.version) == 6 &&
    !window["XMLHttpRequest"];

It appears that these issues were resolved in IE 8 (at least in the beta version), but until jQuery releases a "fix", you'll have to deal with unreliable browser version detection in IE 7, or use one of the suggestions above.

Opera 9.5

I discovered an issue getting the viewport height in Opera 9.5 while testing my rewrite of SimpleModal. It turns out that Opera, in an effort to follow standards, changed where it was storing the value for the viewport height...breaking the way jQuery was getting the value. Previously, the value was stored in document.body["clientHeight"], but in 9.5 it was moved to document.documentElement["clientHeight"]. There is also a jQuery Ticket open for this issue, and a patch has been added by Ariel Flesler.

For SimpleModal, I've added code that will fix the issue until it is fixed in jQuery:

// fix a jQuery/Opera bug with determining the window height
var h = $.browser.opera && $.browser.version > "9.5" &&
    $.fn.jquery <= "1.2.6" ?
        document.documentElement["clientHeight"] :
        $(window).height();

Safari 3 (Windows)

This is the smallest of the three issues, but annoying none-the-less. Take the following example:

$("<div/>").css({
    background: "#336699",
    color: "#fff",
    padding: "8px",
    width: "200px"
}).html("Loading...").hide().appendTo("body");

In Safari, the "loading" element will be visible when the page loads. In all other browsers, it is hidden (display:none). The issue occurs because the jQuery hide() function is supposed to look for "visible" elements and set the CSS display property to 'none'. However, in Safari, it appears that an element not yet in the DOM, already has a display property of 'none'...which sounds fine, right? It's not! Since it fails the visibility test, jQuery does not explicitly set the display property to "none".

Then, once the element is added to the DOM, it appears that Safari sets the elements display property to 'block'. So even though the intention was to have it "hidden", due to a Safari quirk (and lack of a jQuery internal solution), the element will be visible.

As I'm sure you've guessed by now, there is a jQuery Ticket open, but the suggestion is to just change the way you use jQuery. One suggestion is to move the .hide() after the .appendTo("body"). My problem with this is that it introduces the possibility of a flicker on the screen as the element is added and then hidden. The workaround I am using is to manually set the display property on the element:

$("<div/>").css({
    background: "#336699",
    color: "#fff",
    display: "none",
    padding: "8px",
    width: "200px"
}).html("Loading...").appendTo("body");

That concludes my notes about three browser issues I've encountered while using jQuery. If you've run into any issues where you've had to use a workaround, or have any other suggestions for the workarounds I used, feel free to mention them below!

And the moral of the story...use Firefox! :)