jQuery.browser.version Doesn’t Recognise IE7 Anymore
Recently i’ve noticed that jQuery.browser.version seems to be returning 6 for most copies of IE7. This seems to be due to the fact that the user-agent string now contains the substring “MSIE 6.0″. So, thanks for that Microsoft.
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322; .NET
CLR 2.0.50727; .NET CLR 3.0.04506.30)
See what they’ve done there? Genius.
I wouldn’t reccomend using jQuery.browser.version for anything important but if you need to you can weed out IE6 by extending $.browser like this:
The Workaround
$.browser.msie6 =
$.browser.msie
&& /MSIE 6\.0/i.test(window.navigator.userAgent)
&& !/MSIE 7\.0/i.test(window.navigator.userAgent);
The most critical effect of this i’ve seen is with Thickbox. Thickbox identifies the browser as IE6 and incorrectly attempts to position the Thickbox window using an IE6 hack, resulting in the image being displayed off-centre. I’ve detailed how to patch the current 3.1 release on the support forum
Update: More information about this bug and how it affects Thickbox, along with some patched copies of thickbox.js can now be found here
July 2008: A fringe case where Internet Explorer will return a MSIE 6.0 user agent string when the user agent string exceeds 260 characters has been identified. Read more here
June 14th, 2008 at 11:52 pm
Hi, I’ve tried replacing the code after you answered here:
http://wordpress.org/support/topic/173000?replies=7#post-754059 , but I’m still having some errors. Do you think you can take a look?
Thanks.
July 23rd, 2008 at 3:57 pm
I’ve managed to get the ticket for this bug upgraded from minor to major
http://dev.jquery.com/ticket/3169
August 13th, 2008 at 5:31 am
[...] 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. [...]
October 19th, 2008 at 7:22 am
[...] can monitor the jQuery bug in the bug tracker, or see the original research performed by Jamie Thompson. Here’s a better workaround that doesn’t introduce a new property (he’s using $.browser.msie6), but [...]
January 23rd, 2009 at 4:29 pm
This issue seems to affect IE8 as well, but in addition the overlay is no longer transparent but solid black.
Not sure if it’s issues with user agent - could be something else.
http://blogs.msdn.com/ie/archive/2008/02/21/the-internet-explorer-8-user-agent-string.aspx
January 23rd, 2009 at 5:22 pm
Ah, IE8 transparency is actually an issue with IE8 no longer supporting any form of CSS opacity instruction.
As per:
http://ajaxian.com/archives/ie-8-strict-mode-doesnt-allow-for-css-opacity
January 23rd, 2009 at 5:25 pm
Yes, it’s good that, isn’t it
January 23rd, 2009 at 5:41 pm
Heh.
It is actually fixable for the time being (until IE8 changes things again).
As per:
http://www.quirksmode.org/css/opacity.html
You can add
-ms-filter:”progid:DXImageTransform.Microsoft.Alpha(Opacity=75)”;
to the CSS rule and that should sort it.
January 23rd, 2009 at 5:42 pm
Oh and thanks to Denis and filosofo for sorting through all this over at:
http://trac.wordpress.org/ticket/8933
Re: fixing thickbox issues in WordPress admin area.