Detecting Internet Explorer 6
in [JavaScript]
|
From: David Mark on 2 Nov 2009 06:21 On Nov 1, 5:17 pm, Dr J R Stockton <reply0...(a)merlyn.demon.co.uk> wrote: > In comp.lang.javascript message <c7ebf289-542a-4c87-a323-a67f0bbf1bd0(a)m2 > 5g2000vbi.googlegroups.com>, Sat, 31 Oct 2009 17:36:38, David Mark > <dmark.cins...(a)gmail.com> posted: > > > > >On Oct 31, 6:21 pm, Dr J R Stockton <reply0...(a)merlyn.demon.co.uk> > >wrote: > >> In comp.lang.javascript message <e4WdnckhUoAkZXbXnZ2dnUVZ8s- > >> dn...(a)brightview.com>, Sat, 31 Oct 2009 08:43:31, Swifty > >> <steve.j.sw...(a)gmail.com> posted: > > >> >I know that detecting the browser is frowned upon here, but I have a > >> >need to identify specifically Internet Explorer 6. > > >> Testing either > >> (0.007).toFixed(2) > >> or > >> S = "3000000000000000000000000" ; parseFloat(S+".0")/parseFloat(S) > >> will identify IE : the second in at least IE 4 to IE 8, and the first in > >> all versions from the introduction of toFixed to IE 8. Use those in > >> addition to conditional compilation, and you have belt-and-braces. > > >> There is, I suppose, some risk of MS correcting those bugs; but that > >> will not worry you. > > >What should worry you is other implementations with similar bugs. > > Who else would do that? Only the biggest American organisations can > consistently sustain that level of incompetence. > Well, only an incompetent developer would infer anything from that bug (except that toFixed is broken). It certainly isn't a good inference for IE as they could fix that bug at any time and other browser developers are certainly capable of such mistakes. In fact, other browsers are known to replicate IE bugs in quirks mode.
From: SAM on 2 Nov 2009 12:42 Le 10/31/09 8:26 PM, Thomas 'PointedEars' Lahn a �crit : > >> Thomas 'PointedEars' Lahn wrote: >>> <http://my-debugbar.com/wiki/IETester/HomePage> > > An installation of Standalone IE or IE > Tester does not touch the existing DLLs, it provides its own located in its > program directory. However, IE Tester allows you to use the existing ones > when and if it is conventient with the "Default IE" browsing tab. I tried to install this IETester in my Virtual Machine XP Sp2 (and IE6 I believe) and ... it doesn't want to "tab" IE8 ... "impossible to load the asked version" or something like that (in french). Does IE8 must be installed to get IETester testing IE8 ? Usually I prefer my VM to do not be connected to the web. (I downloaded the IETester-install.exe via my Mac) -- sm
From: Dr J R Stockton on 2 Nov 2009 18:42 In comp.lang.javascript message <e1970d70-ed13-4660-a0e1-6941443ada91(a)k4 g2000yqb.googlegroups.com>, Mon, 2 Nov 2009 03:21:16, David Mark <dmark.cinsoft(a)gmail.com> posted: >On Nov 1, 5:17�pm, Dr J R Stockton <reply0...(a)merlyn.demon.co.uk> >wrote: >> In comp.lang.javascript message <c7ebf289-542a-4c87-a323-a67f0bbf1bd0(a)m2 >> 5g2000vbi.googlegroups.com>, Sat, 31 Oct 2009 17:36:38, David Mark >> <dmark.cins...(a)gmail.com> posted: >> >> >> >> >On Oct 31, 6:21�pm, Dr J R Stockton <reply0...(a)merlyn.demon.co.uk> >> >wrote: >> >> In comp.lang.javascript message <e4WdnckhUoAkZXbXnZ2dnUVZ8s- >> >> dn...(a)brightview.com>, Sat, 31 Oct 2009 08:43:31, Swifty >> >> <steve.j.sw...(a)gmail.com> posted: >> >> >> >I know that detecting the browser is frowned upon here, but I have a >> >> >need to identify specifically Internet Explorer 6. >> >> >> Testing either >> >> � � (0.007).toFixed(2) >> >> or >> >> � � S = "3000000000000000000000000" ; parseFloat(S+".0")/parseFloat(S) >> >> will identify IE : the second in at least IE 4 to IE 8, and the first in >> >> all versions from the introduction of toFixed to IE 8. �Use those in >> >> addition to conditional compilation, and you have belt-and-braces. >> >> >> There is, I suppose, some risk of MS correcting those bugs; but that >> >> will not worry you. >> >> >What should worry you is other implementations with similar bugs. >> >> Who else would do that? �Only the biggest American organisations can >> consistently sustain that level of incompetence. >> > >Well, only an incompetent developer would infer anything from that bug >(except that toFixed is broken). It certainly isn't a good inference >for IE as they could fix that bug at any time The OP implied rather strongly that it is IE6 which he wants to detect. MS are unlikely to fix that now. > and other browser >developers are certainly capable of such mistakes. Of mistakes, yes. But Microsoft outclasses the rest in this respect. > In fact, other >browsers are known to replicate IE bugs in quirks mode. Some IE bugs. Mostly ones with visual effect? + + + But, for the second bug (it seems less likely to be invoked; but far more important when it is; to get away with an error of a factor of 10, one probably needs to be a Senator), one should in fact not put too much blame on parseFloat : the bug is wider than that. Try, in IE, S = "3000000000000000000000000" ; X = (+(S+".0"))/(+S) I get 10 (ten) in IE, but 1 in FF & Cr. Remove a fistful of zeroes, and the result changes to 1 in IE. ISTM that the FAQ needs a section on converting long fixed point strings to Number. From memory, ISTM that a RegExp test /\d{19,}\./ will detect where parseInt will cure by truncation. -- (c) John Stockton, nr London UK. ?@merlyn.demon.co.uk BP7, Delphi 3 & 2006. <URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links; <URL:http://www.bancoems.com/CompLangPascalDelphiMisc-MiniFAQ.htm> clpdmFAQ; NOT <URL:http://support.codegear.com/newsgroups/>: news:borland.* Guidelines
From: David Mark on 2 Nov 2009 18:53 On Nov 1, 5:24 am, Eric Bednarz <bedn...(a)fahr-zur-hoelle.org> wrote: > David Mark <dmark.cins...(a)gmail.com> writes: > > [ ] The OP wants to target 6 and > > we know that XMLHttpRequest was not introduced until 7. Combine that > > with detection of ActiveXObject, window.external, > > document.documentElement.filters, > > document.documentElement.style.filter, document.expando, etc. and you > > can be pretty sure you've got IE6 > > If it *has* to be script based for some reason, Id rather combine that > with conditional compilation. Fine, as long as you aren't going by the script engine version. > And then only if a false positive would > just result in an unnecesary performance hit (e.g. using filters where > it isnt necessary), because we also know that the native XMLHttpRequest > object can be disabled in the IE 7/8 preferences. Good point. You would need additional inferences to home in on IE6. It's easy if you avoid quirks mode (e.g. test typeof documentElement.style.maxWidth == 'string'). Glad I never have to think about this as I use conditional comments for the rare occasion that I need to target an old IE version.
From: David Mark on 2 Nov 2009 18:57
On Nov 2, 6:42 pm, Dr J R Stockton <reply0...(a)merlyn.demon.co.uk> wrote: > In comp.lang.javascript message <e1970d70-ed13-4660-a0e1-6941443ada91(a)k4 > g2000yqb.googlegroups.com>, Mon, 2 Nov 2009 03:21:16, David Mark > <dmark.cins...(a)gmail.com> posted: > > > > >On Nov 1, 5:17 pm, Dr J R Stockton <reply0...(a)merlyn.demon.co.uk> > >wrote: > >> In comp.lang.javascript message <c7ebf289-542a-4c87-a323-a67f0bbf1bd0(a)m2 > >> 5g2000vbi.googlegroups.com>, Sat, 31 Oct 2009 17:36:38, David Mark > >> <dmark.cins...(a)gmail.com> posted: > > >> >On Oct 31, 6:21 pm, Dr J R Stockton <reply0...(a)merlyn.demon.co.uk> > >> >wrote: > >> >> In comp.lang.javascript message <e4WdnckhUoAkZXbXnZ2dnUVZ8s- > >> >> dn...(a)brightview.com>, Sat, 31 Oct 2009 08:43:31, Swifty > >> >> <steve.j.sw...(a)gmail.com> posted: > > >> >> >I know that detecting the browser is frowned upon here, but I have a > >> >> >need to identify specifically Internet Explorer 6. > > >> >> Testing either > >> >> (0.007).toFixed(2) > >> >> or > >> >> S = "3000000000000000000000000" ; parseFloat(S+".0")/parseFloat(S) > >> >> will identify IE : the second in at least IE 4 to IE 8, and the first in > >> >> all versions from the introduction of toFixed to IE 8. Use those in > >> >> addition to conditional compilation, and you have belt-and-braces. > > >> >> There is, I suppose, some risk of MS correcting those bugs; but that > >> >> will not worry you. > > >> >What should worry you is other implementations with similar bugs. > > >> Who else would do that? Only the biggest American organisations can > >> consistently sustain that level of incompetence. > > >Well, only an incompetent developer would infer anything from that bug > >(except that toFixed is broken). It certainly isn't a good inference > >for IE as they could fix that bug at any time > > The OP implied rather strongly that it is IE6 which he wants to detect. > MS are unlikely to fix that now. They could (or another browser may exist that is broken in the same way). > > > and other browser > >developers are certainly capable of such mistakes. > > Of mistakes, yes. But Microsoft outclasses the rest in this respect. Yes. > > > In fact, other > >browsers are known to replicate IE bugs in quirks mode. > > Some IE bugs. Mostly ones with visual effect? Yes, mostly. I think this one would be unlikely. Still I think it is a bad inference. |