Cross Browser JavaScript Debugging (Moz/IE)

**Jim Ley** · Jul 23 '05, 10:27 AM

Re: Cross Browser JavaScript Debugging (Moz/IE)

On 18 Apr 2004 16:58:56 -0700, despam2004@yaho o.ca (Java script
Dude) wrote:[color=blue]
>I have build some cross browser debuggers so my
>users can send me verbose debug dumps. I have some success but have
>come to a roadblock with the basic underlying JavaScript models.[/color]

I've never found the need for these sort of call stacks in JS, and
have certainly never found the need for verbose debugging code in
shipped content, it strikes me as suggesting that you're not putting
enough thought into where you're likely to error, and aren't being
defensive enough.
[color=blue]
> 1) My current Production version- use try/catch blocks but put
>them in as many error prone places and as close to error source
>points.[/color]

Surely you should always be catching known errors, and preferably
should be preventing all that are expected, are you really getting
value out of this debug code?
[color=blue]
> 2) Possibility 1 - Structure code such that try/catches only
>operate in Mozilla. This would need simple server side code to serve[/color]

oops, this line has already disqualified yourself from having a clue,
you cannot identify IE/mozilla on the server, by doing so you're just
introducing yourself other problems.
[color=blue]
> I would never even dream of
>suggesting this as a bug to Microsoft as I am morally against having
>to pay to report bugs.[/color]

You don't need to pay to report bugs to MS.
[color=blue]
>Any ideas would be greatly appreciated.[/color]

Write defensive code, use more try/catches in known areas, use the
onerror approach as a final hope catch.

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

**Java script Dude** · Jul 23 '05, 10:28 AM

Re: Cross Browser JavaScript Debugging (Moz/IE)

> >I have build some cross browser debuggers so my[color=blue][color=green]
> >users can send me verbose debug dumps. I have some success but have
> >come to a roadblock with the basic underlying JavaScript models.[/color]
>
> I've never found the need for these sort of call stacks in JS, and
> have certainly never found the need for verbose debugging code in
> shipped content, it strikes me as suggesting that you're not putting
> enough thought into where you're likely to error, and aren't being
> defensive enough.
>[/color]

I am talking about DHTML Applications not pages with JavaScript (DHTML
Page/Document). Applications imply code that uses libraries and will
need to go below 3 levels in a call stack. Without reading a stack
anything more than two levels deep is very difficult (and sometimes
impossible) to debug. I have some JavaScript (That's be on production
for years) that go more than 7 levels deep in the stack. This code may
be complete but at least it is debuggable.

[color=blue][color=green]
> > 1) My current Production version- use try/catch blocks but put
> >them in as many error prone places and as close to error source
> >points.[/color]
>
> Surely you should always be catching known errors, and preferably
> should be preventing all that are expected, are you really getting
> value out of this debug code?
>[/color]

I agree, more handlers is better for debugging (in IE) in Moz, it's
only important to handle the error. How far up the stack does not
matter.

[color=blue][color=green]
> > 2) Possibility 1 - Structure code such that try/catches only
> >operate in Mozilla. This would need simple server side code to serve[/color]
>
> oops, this line has already disqualified yourself from having a clue,
> you cannot identify IE/mozilla on the server, by doing so you're just
> introducing yourself other problems.
>[/color]

Clue numero uno: Try page:
http://cyscape.com/products/bhawk/javabean.asp. You will see that it
can detect Mozilla. (JavaBean.asp? What Sacralige)

[color=blue][color=green]
> > I would never even dream of
> >suggesting this as a bug to Microsoft as I am morally against having
> >to pay to report bugs.[/color]
>
> You don't need to pay to report bugs to MS.[/color]

I have tried before and they always asked me for $ to report the bug I
refused on moral grounds. Bugzilla just takes the bug and fixes it and
even includes me in the process :] Me be happy. If I detect a bug in
IE just work around it, in Moz I report it because it is not in vain.

[color=blue]
>[color=green]
> >Any ideas would be greatly appreciated.[/color]
>
> Write defensive code, use more try/catches in known areas, use the
> onerror approach as a final hope catch.[/color]

I agree completely. Until IE gives us a stack property and Mozilla
gives us the error object at window.onerror, that is the best
technique.

Tim

**Richard Cornford** · Jul 23 '05, 10:29 AM

Re: Cross Browser JavaScript Debugging (Moz/IE)

Java script Dude wrote:
<snip>[color=blue][color=green][color=darkred]
>>> 2) Possibility 1 - Structure code such that try/catches
>>> only operate in Mozilla. This would need simple server side
>>> code to serve[/color]
>>
>> oops, this line has already disqualified yourself from having
>> a clue, you cannot identify IE/mozilla on the server, by doing
>> so you're just introducing yourself other problems.[/color]
>
> Clue numero uno: Try page:
> http://cyscape.com/products/bhawk/javabean.asp. You will see
> that it can detect Mozilla. (JavaBean.asp? What Sacralige)[/color]
<snip>

The statement "you cannot identify IE/mozilla on the server" is not
modified by an instance of someone attempting to sell software that
claims to identify them on the server. The only information that the
server gets about what browser is on the other end of the connection (at
least initially) is the User Agent header, and then is routinely
faked/spoofed (or replaced/modified by intervening proxies).

But why not try their page and see how well it does. IE 6 first (as
getting that wrong would be a very bad sign). The returned page,
entitled BrowserHawk, features the line "Your browser: Netscape 4.0
(Unknown)"; not a good start. Following the link "features and benefits
here" goes to the page with the "demo", and the demo link opens a page
with the words "Performing an extensive browser test. Please wait..",
shortly followed by two JScript error reports reading -
"navigator.lang uage" is null or not an object - (which is of course true
on IE 6) and that is it.

Having failed totally at identifying IE 6, because it is not a default
configuration of IE 6 (though that isn't a good excuse as web browsers
are designed to be configurable) I thought I would try it with default
configurations of a couple of less common browsers. IceBrowser 5.4 to
start with. This time BrowserHawk is convinced it is dealing with IE 5,
and again errors on the "Performing an extensive browser test. Please
wait.." page because IceBrowser doesn't implement Microsoft's
ScriptEngine methods.

Next, Web Browser 2.0, this time reported as IE 6 by BrowserHawk, and
again errors on the "extensive browser test" page, prematurely
terminating the testing process.

So that is three browsers (including the most common one used) and 3
failures to identify, followed by 3 errors generated on the test page,
resulting in a failure to complete the test process. It looks like
whoever implemented BrowserHawk didn't have a clue either, but then
looking at the source of the test page turned up this gem:-

<noscript><bo dy BGCOLOR=#000066
TEXT=#FFFFFF onLoad="bhawkTe st();"></noscript>
<script>documen t.write(
'<body BGCOLOR=#000066 TEXT=#FFFFFF onLoad="bhawkTe st();">'
);</script>

- which rather confirms that impression.

Richard.

**Java script Dude** · Jul 23 '05, 10:29 AM

Re: Cross Browser JavaScript Debugging (Moz/IE)

> > Clue numero uno: Try page:[color=blue][color=green]
> > http://cyscape.com/products/bhawk/javabean.asp. You will see
> > that it can detect Mozilla. (JavaBean.asp? What Sacralige)[/color]
>
> The statement "you cannot identify IE/mozilla on the server" is not
> modified by an instance of someone attempting to sell software that
> claims to identify them on the server. The only information that the
> server gets about what browser is on the other end of the connection (at
> least initially) is the User Agent header, and then is routinely
> faked/spoofed (or replaced/modified by intervening proxies).[/color]

True, if proxies are spoofing the User Agent then we are all toast
anyway. It does not matter what browser you use really. The original
argument was that Mozilla cannot be detected.

I wrote a simple JSP that dump's the User Agent:

<%
out.println(req uest.getHeader( "USER-AGENT"));
%>
Outputs:
Mozilla - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6)
Gecko/20040206 Firefox/0.8
IE - Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

Clearly, as long as the User Agent is not 'spoofed' any (decent)
programmer can parse this string and figure out what browser is at the
other end.

Such a programmer could also remove the need to detect the browser
version on the server if they write good DHTML and they could even
write a simple client side gateway for detecting the browser (IF JS is
enabled of course).

I do plead a bit of ignorance here though as I build multi-user
intranet based PDM systems that only require IE 5.5sp2 as a base. I
develop in Mozilla not becuase of a customers need but because of a
need to develop open standard, stable and extensible code. As such
server side browser detection is not necessary. Also there is no
'spoofing' happening within our intranet of course.

I guess I'm a little spoiled :]

Tim

**Lasse Reichstein Nielsen** · Jul 23 '05, 10:29 AM

Re: Cross Browser JavaScript Debugging (Moz/IE)

despam2004@yaho o.ca (Java script Dude) writes:
[color=blue]
> True, if proxies are spoofing the User Agent then we are all toast
> anyway.[/color]

Yes, and they are.
[color=blue]
> Clearly, as long as the User Agent is not 'spoofed' any (decent)
> programmer can parse this string and figure out what browser is at the
> other end.[/color]

No. That would require him to have knowledge of all browsers in
existence, and their variants of user agent strings.

If the script is to be future-proof, he must also be able to
anticipate comming browsers and their user agent strings. At worst,
they could be identical to an existing browsers'.

This is ofcourse aburd. However, if ones pages depends on browser
sniffing, these are real problems.
[color=blue]
> Such a programmer could also remove the need to detect the browser
> version on the server if they write good DHTML and they could even
> write a simple client side gateway for detecting the browser (IF JS is
> enabled of course).[/color]

And if Javascript is not enabled, will his page fail? :)
[color=blue]
> I do plead a bit of ignorance here though as I build multi-user
> intranet based PDM systems that only require IE 5.5sp2 as a base.
> I develop in Mozilla not becuase of a customers need but because of
> a need to develop open standard, stable and extensible code.[/color]

That is a recommendable goal. I would do the same if I were doing
Javascript for a living :)

I do think you underestimate the number and variety of browsers that
are available, and how prevalent user agent faking is (which is
ofcourse impossible to tell, since good faking doesn't stand out in
the server logs.)

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

**Richard Cornford** · Jul 23 '05, 10:29 AM

Re: Cross Browser JavaScript Debugging (Moz/IE)

Java script Dude wrote:[color=blue][color=green][color=darkred]
>> > Clue numero uno: Try page:
>> > http://cyscape.com/products/bhawk/javabean.asp. You will see
>> > that it can detect Mozilla. (JavaBean.asp? What Sacralige)[/color]
>>
>> The statement "you cannot identify IE/mozilla on the server" is not
>> modified by an instance of someone attempting to sell software that
>> claims to identify them on the server. The only information that the
>> server gets about what browser is on the other end of the connection
>> (at least initially) is the User Agent header, and then is routinely
>> faked/spoofed (or replaced/modified by intervening proxies).[/color]
>
> True, if proxies are spoofing the User Agent then we are
> all toast anyway.[/color]

No we are not. It is well known that User Agent headers are not a
discriminating indicator of the type or version of client-side software,
and that has been true for some considerable time. That makes no
practical difference to client-side scripting because browser detecting
is not necessary for client-side scripting, and there is no really good
reason for server-side scripts to be interested either as they are
mostly in the business of generating HTML (which browsers are designed
to understand).
[color=blue]
> It does not matter what browser you use really. The original
> argument was that Mozilla cannot be detected.[/color]

And it cannot be detected. Mozilla's User Agent header is just as
amenable to user modification as any other browser's, and any other
browser is at liberty to send a User Agent header that is
indistinguishab le form one that is a default in a Mozilla version (a
number directly provide the user with an option to spoof Mozilla in
their preferences).
[color=blue]
> I wrote a simple JSP that dump's the User Agent:
>
> <%
> out.println(req uest.getHeader( "USER-AGENT"));
> %>
> Outputs:
> Mozilla - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6)
> Gecko/20040206 Firefox/0.8
> IE - Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
>
> Clearly, as long as the User Agent is not 'spoofed' any (decent)
> programmer can parse this string and figure out what browser is at the
> other end.[/color]

But that caveat instantly becomes the fatal flaw in the plan, as User
Agent headers are routinely spoofed by the majority of browsers. It is
the norm not the exception. Many use spoofed headers that still leave a
clue as to which browser it really is, but there are still a number that
are just indistinguishab le form some more common browser by default.
[color=blue]
> Such a programmer could also remove the need to detect the browser
> version on the server if they write good DHTML and they could even
> write a simple client side gateway for detecting the browser (IF JS is
> enabled of course).[/color]

No, you can't detect the browser on the client either. You either
immediately fall back into the user agent string trap, or you would need
to employ a discriminating object inference technique, which
pre-supposes a omniscient knowledge of all web browser DOMs (past,
present and future).

But the combination of the facts that this group has a particular
interest in browser DOMs and that there is nobody contributing to this
group who will even claim to be able to name all web browser, let alone
to know enough to infer a browser type and version from any given DOM,
suggest that there is nobody with enough knowledge to write a truly
discriminating object inference script even for browsers that currently
exist.

Fortunately identifying browsers is unnecessary, so the impossibility of
the task is not a problem.
[color=blue]
> I do plead a bit of ignorance here though as I build multi-user
> intranet based PDM systems that only require IE 5.5sp2 as a base. I
> develop in Mozilla not becuase of a customers need but because of a
> need to develop open standard, stable and extensible code.[/color]

Didn't you start a thread expounding your notions of how to go about
browser scripting? Was that a good idea given that you only author for
two browsers (and appear to be optimistic about aspects of their
behaviour) and with the expectation that the results will only be used
in a known environment?
[color=blue]
> As such
> server side browser detection is not necessary. Also there is no
> 'spoofing' happening within our intranet of course.[/color]

Yes, take away the Internet and much of the cautious, defensive
scripting and strategic script design becomes unnecessary. But then
those are the aspects of browser scripting that makes it interesting and
challenging.

Richard.

**Matt Kruse** · Jul 23 '05, 10:29 AM

Re: Cross Browser JavaScript Debugging (Moz/IE)

"Richard Cornford" <Richard@litote s.demon.co.uk> wrote:[color=blue]
> It is well known that User Agent headers are not a
> discriminating indicator of the type or version of client-side software,
> and that has been true for some considerable time.[/color]

I would be interested in some real statistics on this question.
My hunch is that the vast majority of user agent headers are accurate and
not misrepresentati ons of the client being used.
[color=blue]
> because browser detecting
> is not necessary for client-side scripting[/color]

Well, I wouldn't say that is completely true.
There are times when browser-sniffing is certainly necessary. For example,
when a particular version of a particular browser has a bug or quirk which
must be specially accomodated. There are some features/bugs which are not
detectable by inspecting the dom or testing for properties/methods, and must
be accounted for by looking at the exact browser being used.
[color=blue]
> But that caveat instantly becomes the fatal flaw in the plan, as User
> Agent headers are routinely spoofed by the majority of browsers. It is
> the norm not the exception.[/color]

Why do you say this? I look at my logs and see very common user agent
strings.
[color=blue]
> Fortunately identifying browsers is unnecessary, so the impossibility of
> the task is not a problem.[/color]

It's not completely unnecessary, but for most situations it is.
Further, although the task may be impossible (I agree), there may be value
in solving the problem 99.9% of the way.

--
Matt Kruse
Javascript Toolbox: http://www.mattkruse.com/javascript/

**Richard Cornford** · Jul 23 '05, 10:30 AM

Re: Cross Browser JavaScript Debugging (Moz/IE)

Matt Kruse wrote:[color=blue]
> "Richard Cornford" wrote:[color=green]
>> It is well known that User Agent headers are not a
>> discriminating indicator of the type or version of client-side
>> software, and that has been true for some considerable time.[/color]
>
> I would be interested in some real statistics on this question.[/color]

You haven't really thought that through. How would it be possible to
gather statistics on the extent to which things were indistinguishab le?
[color=blue]
> My hunch is that the vast majority of user agent headers are accurate
> and not misrepresentati ons of the client being used.[/color]

It wouldn't matter if they were as it remains impossible to tell, and a
minority that tells lies still invalidates the proposition that it
browser type or version can be detected.
[color=blue][color=green]
>> because browser detecting
>> is not necessary for client-side scripting[/color]
>
> Well, I wouldn't say that is completely true. There are
> times when browser-sniffing is certainly necessary. For
> example, when a particular version of a particular browser
> has a bug or quirk which must be specially accomodated.[/color]

Any proposed action that necessitates an impossibility is misguided. But
there are not that many examples of browser bugs that cannot be exposed
by appropriate feature detecting, or avoided entirely by taking a more
reliable approach (if there are actually any, none have been
specifically mentioned as examples).
[color=blue]
> There are some
> features/bugs which are not detectable by inspecting the dom or
> testing for properties/methods, and must be accounted for by looking
> at the exact browser being used.[/color]

There are no techniques available to identify the exact browser being
used.
[color=blue][color=green]
>> But that caveat instantly becomes the fatal flaw in the plan, as User
>> Agent headers are routinely spoofed by the majority of browsers. It
>> is the norm not the exception.[/color]
>
> Why do you say this?[/color]

Because it is true.
[color=blue]
> I look at my logs and see very common user agent
> strings.[/color]

When the majority of less common browsers actively spoof the User Agent
headers of more common browsers, or make a facility for doing so easily
available to their users and an insistence on the part of web site
designers in reading UA headers and serving unhelpful comments up to the
users of browsers they have never heard of encourages the users of those
less well known browsers to use the facilities they have for spoofing,
then the expected result would be the logging of only a limited number
of user agent strings, only those normally produced by the most common
browser.

But then your own logs will not be representative anyway as your
unwillingness to accommodate browsers that do not conform to your
expectations will not leave the users of those browsers with the
impression that visiting your site is a productive way of spending their
time.
[color=blue][color=green]
>> Fortunately identifying browsers is unnecessary, so the
>> impossibility of the task is not a problem.[/color]
>
> It's not completely unnecessary, but for most situations it is.
> Further, although the task may be impossible (I agree), there may be
> value in solving the problem 99.9% of the way.[/color]

You love wheeling out arbitrary statistics. The only logical way of
dealing with the impossibility of accurately discriminating between web
browsers (and/or browser versions) is to seek to avoid the need to do so
at all.

As techniques exist that remove the need to identify browsers it makes
more sense to learn and refine those then to spend time an effort
failing to achieve the impossible (no matter how close your
head-in-the-sand attitude may leave you believing you could get).

Richard.

**Matt Kruse** · Jul 23 '05, 10:30 AM

Re: Cross Browser JavaScript Debugging (Moz/IE)

"Richard Cornford" <Richard@litote s.demon.co.uk> wrote:[color=blue]
> You haven't really thought that through. How would it be possible to
> gather statistics on the extent to which things were indistinguishab le?[/color]

A survey of Opera/Mozilla users, for example, to find out how many
manipulate their UA strings. Etc, etc.
It's not an impossible task, although it may not be partcularly useful.
[color=blue][color=green]
> > My hunch is that the vast majority of user agent headers are accurate
> > and not misrepresentati ons of the client being used.[/color]
> It wouldn't matter if they were as it remains impossible to tell, and a
> minority that tells lies still invalidates the proposition that it
> browser type or version can be detected.[/color]

It doesn't invalidate the proposition that in the vast majority of cases,
browser type and version can be detected accurately.
AFAIK, no one was proposing that it was a fool-proof, 100% solution.
[color=blue]
> Any proposed action that necessitates an impossibility is misguided.[/color]

Laughable.
Many things are viewed as "impossible " until someone does them to a
satisfactory degree.
[color=blue]
> There are no techniques available to identify the exact browser being
> used.[/color]

There are techniques available to identify the browser that the user says is
being used.
If the user is lying, then they learn to live with the results.
[color=blue][color=green][color=darkred]
> >> Agent headers are routinely spoofed by the majority of browsers. It
> >> is the norm not the exception.[/color]
> > Why do you say this?[/color]
> Because it is true.[/color]

Any evidence of this? I think you are mistaken.
[color=blue]
> When the majority of less common browsers actively spoof the User Agent
> headers of more common browsers, or make a facility for doing so easily
> available to their users and an insistence on the part of web site
> designers in reading UA headers and serving unhelpful comments up to the
> users of browsers they have never heard of encourages the users of those
> less well known browsers to use the facilities they have for spoofing,
> then the expected result would be the logging of only a limited number
> of user agent strings, only those normally produced by the most common
> browser.[/color]

The answer would seem to be that users of Opera and Mozilla or any other
browser which allows for manipulating the UA header should stop using that
feature. Then those people who _do_ decide to use browser-sniffing will
incorporate support for their browsers.
[color=blue][color=green]
> > Further, although the task may be impossible (I agree), there may be
> > value in solving the problem 99.9% of the way.[/color]
> You love wheeling out arbitrary statistics.[/color]

Well, 94% of the time, they're right. HA!
[color=blue]
> The only logical way of
> dealing with the impossibility of accurately discriminating between web
> browsers (and/or browser versions) is to seek to avoid the need to do so
> at all.[/color]

Again, you need to learn that the world is not black-and-white. Solutions
which solve the problem in almost all cases, for almost all users, can
provide a lot of value. A problem does not have to be solved 100% in order
for it to provide value. Progress and learning _depends_ on people solving
problems partially, so that others can piggy-back on their learning and
improve the solutions.
[color=blue]
> As techniques exist that remove the need to identify browsers it makes
> more sense to learn and refine those then to spend time an effort
> failing to achieve the impossible (no matter how close your
> head-in-the-sand attitude may leave you believing you could get).[/color]

Let me be clear about what I'm saying:

1) Browser-sniffing, in most cases, is not necessary. There are better ways
to do it. Usually.

2) In the event that sniffing is necessary, it's often reliable. No modern
browser is going to spoof being IE4. If you're in a corporate environment
where some older machines may still have IE4 installed, and you want to
direct those users to an upgrade or contact page before allowing them to
enter your intranet portal, server-side browser sniffing is a very good
idea. Or if you are writing some client-side code which will break in Opera5
(since it has some missing js functionality which cannot be tested for
directly) then sniffing for that particular version on the client side might
be a good idea.

3) For people who choose to use browsers that enable spoofing of the UA
header, if they choose to use that feature, then they should be willing to
accept the results from a server who trusts that they aren't lying to it. If
they want to encourage the use of these new browsers, they should not be
hiding their real identity, which will only result in people seeing no need
to correctly identify them.

4) Identifying 100% of the browsers out there is an impossible goal.
Identfying specific browsers and versions which you want to take action on
usually is very possible, and might provide value to the developer.

--
Matt Kruse
Javascript Toolbox: http://www.mattkruse.com/javascript/

**Jim Ley** · Jul 23 '05, 10:30 AM

Re: Cross Browser JavaScript Debugging (Moz/IE)

On Mon, 26 Apr 2004 11:57:40 -0500, "Matt Kruse"
<newsgroups@mat tkruse.com> wrote:
[color=blue]
>It doesn't invalidate the proposition that in the vast majority of cases,
>browser type and version can be detected accurately.[/color]

Yet no-one is very good at pointing to a URL which does that, we will
all agree that with sufficient work you could detect todays and
tomorrows browsers reasonably well, but no-one has yet seemed to put
in that effort.
[color=blue]
>Many things are viewed as "impossible " until someone does them to a
>satisfactory degree.[/color]

This would seem like the perfect opportunity for you to go for it
then!
[color=blue]
>If the user is lying, then they learn to live with the results.[/color]

Except of course even if not lying you're assuming you know the
capabilities of the browser - what are the capabilities of IE6sp2 ?
[color=blue][color=green][color=darkred]
>> >> Agent headers are routinely spoofed by the majority of browsers. It
>> >> is the norm not the exception.
>> > Why do you say this?[/color]
>> Because it is true.[/color]
>
>Any evidence of this? I think you are mistaken.[/color]

IE4,5.5,6.0 all spoof themselves as Mozilla /4.0

of course you could then argue that they identify themselves later as
IE, but...
[color=blue]
>The answer would seem to be that users of Opera and Mozilla or any other
>browser which allows for manipulating the UA header should stop using that
>feature. Then those people who _do_ decide to use browser-sniffing will
>incorporate support for their browsers.[/color]

That would not be in their self-interest (due to the lag in getting it
implemented)
[color=blue]
>Again, you need to learn that the world is not black-and-white. Solutions
>which solve the problem in almost all cases, for almost all users, can
>provide a lot of value.[/color]

Sure they can, but no-ones yet come up with a solution which involves
browser scripting that I've seen that wouldn't be better solved in
another way. Often people say it's to exclude certain old NN4 bugs,
but they're a tiny minority anyway, you might aswell just stuff them,
as a different subset of people that carries a significant development
overhead.

You've also ignored on the server the significant extra load (if you
ensure that caches are not used) or the problem of people being served
the wrong version from the proxy cache, if the first user is Lynx, and
the proxy cache caches it, you're really stuffed all your users end up
getting that one!
[color=blue]
>2) In the event that sniffing is necessary, it's often reliable. No modern
>browser is going to spoof being IE4. If you're in a corporate environment
>where some older machines may still have IE4 installed, and you want to
>direct those users to an upgrade or contact page before allowing them to
>enter your intranet portal, server-side browser sniffing is a very good
>idea.[/color]

not really as IE4/IE5 can be 100% detected on the client without
failure, yet doing it on the server is likely to break in a number of
conditions if there are any proxies in the way, and yes in the
corporate environment I live in there are caching proxies in the
intranet.

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

**Lasse Reichstein Nielsen** · Jul 23 '05, 10:30 AM

Re: Cross Browser JavaScript Debugging (Moz/IE)

"Matt Kruse" <newsgroups@mat tkruse.com> writes:

[User-Agent spoofing][color=blue]
> I would be interested in some real statistics on this question.
> My hunch is that the vast majority of user agent headers are accurate and
> not misrepresentati ons of the client being used.[/color]

My hunch is that the vast majority of User Agent headers are claiming
to be some version of IE. Most of them are likely to be correct,
although definitly not all, and there are IE's disguising as something
else too. How many is impossible to tell if they do it well.

The real problem comes with browsers apart from IE. Pretty much any
modern non-IE browser allows the user to disguise as IE to some
extend. Opera's *default* installation masquerades as IE, although
distinguishable by someone who knows where to look.

My hunch is that a significant portion of these spoofs their user
agent string at times. I only do it for certain sites (like MSDN),
or for pages that refuse me access based on my browser.

It is ofcourse impossible to make statistics, because it would
required one to be able to distinguish browsers, to detect the ones
that tries to be undetectable. Whatever statistics someone comes up
with, there is no way to verify it. No way to know which disguises
slipped through.
[color=blue]
> Why do you say this? I look at my logs and see very common user agent
> strings.[/color]

Common user agent strings are exactly what a spoofer would use. Most
likely a recent version of IE.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

**Lasse Reichstein Nielsen** · Jul 23 '05, 10:30 AM

Re: Cross Browser JavaScript Debugging (Moz/IE)

"Matt Kruse" <newsgroups@mat tkruse.com> writes:
[color=blue]
> Let me be clear about what I'm saying:
>
> 1) Browser-sniffing, in most cases, is not necessary. There are better ways
> to do it. Usually.
>
> 2) In the event that sniffing is necessary, it's often reliable. No modern
> browser is going to spoof being IE4.[/color]
....[color=blue]
> 3) For people who choose to use browsers that enable spoofing of the UA
> header, if they choose to use that feature, then they should be willing to
> accept the results from a server who trusts that they aren't lying to it.[/color]
....[color=blue]
> 4) Identifying 100% of the browsers out there is an impossible goal.
> Identfying specific browsers and versions which you want to take action on
> usually is very possible, and might provide value to the developer.[/color]

I have to agree with all of this.

The point being that browser detection is used to build a black-list
of browsers that need special attention, and that will *usually* be
browsers that people are unlikely to spoof as (although I find that IE
6 requires a significant amount of special attention :).

If everybody identifies correctly, then the page will work.

The bad use of browser detection is to use it with a white-list, and
fail on unrecognizable browsers. That is, sadly, often the way it is
used in scripts found on the internet.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

**Richard Cornford** · Jul 23 '05, 10:30 AM

Re: Cross Browser JavaScript Debugging (Moz/IE)

Matt Kruse wrote:[color=blue]
> "Richard Cornford" wrote:[/color]
<snip>[color=blue][color=green][color=darkred]
>> > My hunch is that the vast majority of user agent headers are
>> > accurate and not misrepresentati ons of the client being used.[/color]
>> It wouldn't matter if they were as it remains impossible to tell,
>> and a minority that tells lies still invalidates the proposition
>> that it browser type or version can be detected.[/color]
>
> It doesn't invalidate the proposition that in the vast majority of
> cases, browser type and version can be detected accurately.[/color]

Without any additional information, if you were asked to guess what web
browser an individual used you would be a fool to guess anything but IE
6, and in the vast majority of cases you would be correct. That correct
result could be no more than a coincidence, resulting form nothing more
than the distribution of browsers in use.

If the criteria for browser detecting is no more than a probability of a
correct result then blind guesswork satisfies it, no need to write any
code for that at all.
[color=blue]
> AFAIK, no one was proposing that it was a fool-proof, 100% solution.[/color]

The code at the posted URL makes a claim very much approaching that.
There certainly is no caveat stating that it fails uncontrollably in the
face of anything out of the ordinary.
[color=blue][color=green]
>> Any proposed action that necessitates an impossibility is misguided.[/color]
>
> Laughable.
> Many things are viewed as "impossible " until someone does them to a
> satisfactory degree.[/color]

Some things are logically impossible, and determining the nature of the
client side software from the User Agent header is one of those. That
just follows from the nature of string data, two browsers sending the
same UA header cannot be distinguished using that header. If you think
they can you would be in a position to tell me which three browsers on
the computer I am currently sitting at send the header:-

Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)

- by default. Guesswork will get you one, research may reveal a second,
but nothing will tell you which one of the three I actually copied the
string form to paste it into this article, that information is not part
of the string and is impossible to determine from the string.
[color=blue][color=green]
>> There are no techniques available to identify the exact browser being
>> used.[/color]
>
> There are techniques available to identify the browser that the user
> says is being used.
> If the user is lying, then they learn to live with the results.[/color]

It is always the same with you when you don't want to recognise an
issue, it is the browser's fault, or it is the user's fault. It isn't
ether's fault that UA headers are not discriminating, the HTTP 1.1
specification doesn't require that they should be, because spoofing was
already the norm when the specification was written so it was already to
late to make any strong requirements on what the UA header should
contain. The fault is in expecting a discriminating UA header to be
used, and lies with the software author for trying to deduce anything
from a header that is not specified to be a source of information.
[color=blue][color=green][color=darkred]
>> >> Agent headers are routinely spoofed by the majority of browsers.
>> >> It is the norm not the exception.
>> > Why do you say this?[/color]
>> Because it is true.[/color]
>
> Any evidence of this?[/color]

The User Agent headers sent by web browsers.
[color=blue]
> I think you are mistaken.[/color]

Clearly.

<snip>[color=blue]
> The answer would seem to be that users of Opera and Mozilla or any
> other browser which allows for manipulating the UA header should stop
> using that feature.[/color]

The feature is provided because it is needed, and the browsers that use
spoofed headers by default do not always provide any options in the
preferences to change that so most users of those browsers will not even
be aware that it is happening.
[color=blue]
> Then those people who _do_ decide to use
> browser-sniffing will incorporate support for their browsers.[/color]

If the people who use browser-sniffing could be relied upon to support
all browsers that provided a discriminating UA header then there would
have been no need for Microsoft to start the spoofing ball rolling in
the late nineties. In reality server side browser detecting is used to
exclude unrecognised browser, and the manufacturers of those browsers
are not motivated to make it easy for their products to be needlessly
excluded.
[color=blue][color=green][color=darkred]
>> > Further, although the task may be impossible (I agree), there may
>> > be value in solving the problem 99.9% of the way.[/color]
>> You love wheeling out arbitrary statistics.[/color]
>
> Well, 94% of the time, they're right. HA![/color]

More guesswork?
[color=blue][color=green]
>> The only logical way of
>> dealing with the impossibility of accurately discriminating between
>> web browsers (and/or browser versions) is to seek to avoid the need
>> to do so at all.[/color]
>
> Again, you need to learn that the world is not black-and-white.
> Solutions which solve the problem in almost all cases, for almost all
> users, can provide a lot of value.[/color]

Feature detecting already satisfies (exceeds) those criteria.
[color=blue]
> A problem does not have to be
> solved 100% in order for it to provide value. Progress and learning
> _depends_ on people solving problems partially, so that others can
> piggy-back on their learning and improve the solutions.[/color]

Feature detecting is already significantly better at addressing the
problem than browser detecting. It avoids any need to be interested in
the type of browser so inherent limitations in browser detection are
rendered insignificant and it is already capable of 100% discrimination
in most practical applications. If people want to piggyback their
learning on improving a solution it makes more sense to start with the
best of what is available.
[color=blue][color=green]
>> As techniques exist that remove the need to identify browsers it
>> makes more sense to learn and refine those then to spend time an
>> effort failing to achieve the impossible (no matter how close your
>> head-in-the-sand attitude may leave you believing you could get).[/color]
>
> Let me be clear about what I'm saying:
>
> 1) Browser-sniffing, in most cases, is not necessary. There are
> better ways to do it. Usually.
>
> 2) In the event that sniffing is necessary,[/color]

We don't see any examples of where sniffing is actually necessary, just
assertions that they exist.
[color=blue]
> it's often reliable.[/color]

Guessing the browser is also often reliable, that doesn't make it a
strategy that is likely to produce reliable browser scripts.

<snip>[color=blue]
> ... . Or if you are writing some
> client-side code which will break in Opera5 (since it has some
> missing js functionality which cannot be tested for directly)[/color]

And does Opera 5 have any missing JS functionality that cannot be
detected? And if so, what exactly?
[color=blue]
> then sniffing for that particular version on
> the client side might be a good idea.[/color]

And if the proposed missing functionality can be detected browser
sniffing becomes a bad idea in comparison (as any other browser may also
lack that functionality).
[color=blue]
> 3) For people who choose to use browsers that enable spoofing of the
> UA header, if they choose to use that feature, then they should be
> willing to accept the results from a server who trusts that they
> aren't lying to it. If they want to encourage the use of these new
> browsers, they should not be hiding their real identity, which will
> only result in people seeing no need to correctly identify them.[/color]

That does not correspond with what has happened historically. Browsers
didn't start spoofing because they could, they started it to avoid
arbitrary exclusion by web sites using browser detecting based on the UA
strings.
[color=blue]
> 4) Identifying 100% of the browsers out there is an impossible goal.
> Identfying specific browsers and versions which you want to take
> action on usually is very possible,[/color]

No, receiving a User Agent header that corresponds 100% with the UA
header normally sent by a particular common browsers cannot in itself be
used to deduce the nature of the originating software. To say that
assuming it originated with the common web browser will usually be
correct is to say no more than that common browsers are more common than
other software impersonating common browsers.
[color=blue]
> and might provide value to the
> developer.[/color]

Or it may distract them form pursuing a more valuable alternative.

Richard.

**Thomas 'PointedEars' Lahn** · Jul 23 '05, 10:30 AM

Re: Cross Browser JavaScript Debugging (Moz/IE)

Java script Dude wrote:
[color=blue][color=green][color=darkred]
>> > Clue numero uno: Try page:
>> > http://cyscape.com/products/bhawk/javabean.asp. You will see
>> > that it can detect Mozilla. (JavaBean.asp? What Sacralige)[/color]
>>
>> The statement "you cannot identify IE/mozilla on the server" is not
>> modified by an instance of someone attempting to sell software that
>> claims to identify them on the server. The only information that the
>> server gets about what browser is on the other end of the connection (at
>> least initially) is the User Agent header, and then is routinely
>> faked/spoofed (or replaced/modified by intervening proxies).[/color]
>
> True, if proxies are spoofing the User Agent then we are all toast
> anyway.[/color]

*You* are toast anyway. Good programmers make use of the UA header only
when necessary (when feature detection is not enough to workaround known
bugs) but they do not rely on it.
[color=blue]
> It does not matter what browser you use really. The original
> argument was that Mozilla cannot be detected.
>
> I wrote a simple JSP that dump's the User Agent:
>
> <%
> out.println(req uest.getHeader( "USER-AGENT"));
> %>
> Outputs:
> Mozilla - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6)
> Gecko/20040206 Firefox/0.8
> IE - Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
>
> Clearly, as long as the User Agent is not 'spoofed' any (decent)
> programmer can parse this string and figure out what browser is at the
> other end. [...][/color]

Read <http://pointedears.de. vu/scripts/test/whatami> and get baked ;-)

PointedEars

Cross Browser JavaScript Debugging (Moz/IE)

Cross Browser JavaScript Debugging (Moz/IE)

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment