Detecting Internet Explorer 6

On Nov 1, 5:17*pm, Dr J R Stockton <reply0... (AT) merlyn (DOT) demon.co.uk>
wrote:

In comp.lang.javascript message <c7ebf289-542a-4c87-a323-a67f0bbf1bd0@m2
5g2000vbi.googlegroups.com>, Sat, 31 Oct 2009 17:36:38, David Mark
dmark.cins... (AT) gmail (DOT) com> posted:



On Oct 31, 6:21*pm, Dr J R Stockton <reply0... (AT) merlyn (DOT) demon.co.uk
wrote:
In comp.lang.javascript message <e4WdnckhUoAkZXbXnZ2dnUVZ8s-
dn... (AT) brightview (DOT) com>, Sat, 31 Oct 2009 08:43:31, Swifty
steve.j.sw... (AT) gmail (DOT) 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.

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

In comp.lang.javascript message <e1970d70-ed13-4660-a0e1-6941443ada91@k4
g2000yqb.googlegroups.com>, Mon, 2 Nov 2009 03:21:16, David Mark
<dmark.cinsoft (AT) gmail (DOT) com> posted:

On Nov 1, 5:17*pm, Dr J R Stockton <reply0... (AT) merlyn (DOT) demon.co.uk
wrote:
In comp.lang.javascript message <c7ebf289-542a-4c87-a323-a67f0bbf1bd0@m2
5g2000vbi.googlegroups.com>, Sat, 31 Oct 2009 17:36:38, David Mark
dmark.cins... (AT) gmail (DOT) com> posted:



On Oct 31, 6:21*pm, Dr J R Stockton <reply0... (AT) merlyn (DOT) demon.co.uk
wrote:
In comp.lang.javascript message <e4WdnckhUoAkZXbXnZ2dnUVZ8s-
dn... (AT) brightview (DOT) com>, Sat, 31 Oct 2009 08:43:31, Swifty
steve.j.sw... (AT) gmail (DOT) 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

On Nov 1, 5:24*am, Eric Bednarz <bedn... (AT) fahr-zur-hoelle (DOT) org> wrote:

David Mark <dmark.cins... (AT) gmail (DOT) 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, I’d 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 isn’t 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.

On Nov 2, 6:42*pm, Dr J R Stockton <reply0... (AT) merlyn (DOT) demon.co.uk>
wrote:

In comp.lang.javascript message <e1970d70-ed13-4660-a0e1-6941443ada91@k4
g2000yqb.googlegroups.com>, Mon, 2 Nov 2009 03:21:16, David Mark
dmark.cins... (AT) gmail (DOT) com> posted:



On Nov 1, 5:17*pm, Dr J R Stockton <reply0... (AT) merlyn (DOT) demon.co.uk
wrote:
In comp.lang.javascript message <c7ebf289-542a-4c87-a323-a67f0bbf1bd0@m2
5g2000vbi.googlegroups.com>, Sat, 31 Oct 2009 17:36:38, David Mark
dmark.cins... (AT) gmail (DOT) com> posted:

On Oct 31, 6:21*pm, Dr J R Stockton <reply0... (AT) merlyn (DOT) demon.co.uk
wrote:
In comp.lang.javascript message <e4WdnckhUoAkZXbXnZ2dnUVZ8s-
dn... (AT) brightview (DOT) com>, Sat, 31 Oct 2009 08:43:31, Swifty
steve.j.sw... (AT) gmail (DOT) com> posted:

I know that detecting the browser is frowned upon here, but I havea
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 thosein
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.

David Mark wrote:

If it *has* to be script based for some reason, I’d rather combine that
with conditional compilation.

Fine, as long as you aren't going by the script engine version.

As the OP, I'd just like to assert that I'll be adding the test in my
CGI scripts, which generate all of the affected pages. I chose this
newsgroup because this is the best place to find people who know about
browser detection. I wouldn't trust my Javascript much beyond putting
the focus in the first field of my forms.

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk