Email conversation
| From | Marc Boucher |
|---|
| To | Me |
|---|
| Subject | "browser sniffer" modifications |
|---|
| Date | 20 September 2007 17:26 |
|---|
Hello,
I'm using your "browser sniffer" script to detect browsers in a central
point in my script, and use this detection to work around bugs (instead of
using object detection each time).
I had one problem with the order in which you detect browsers. Gecko and
IE, which can modify their user-agent string, are placed below detections
based on the user-agent string. This means that, mainly when gecko is
spoofing, it can be misidentified.
For this reason I have moved detection for these browsers above other
tests. I'm also using a more efficient way to detect IE (based on
conditional compilation only supported by MS).
Before your first test place this:
/*@cc_on
@if (@_jscript_version <= 3.01) IE=4
@elif (@_jscript_version <= 5.1) IE=5
@elif (@_jscript_version <= 5.5) IE=5.5
@elif (@_jscript_version <= 5.6) IE=6
@elif (@_jscript_version > 5.6) IE=7
@end @*/
(note: jscript_version numbers are reliable, the build number is the only
value that changes regularly on updates.)
and start your tests with:
if(IE){yB[0]='ie'+IE}
Just below I place the new detection for gecko. It seems to be the only
browser to have this type of object:
else if(window.controllers=='[object XULControllers]'){yB[0]='gek'}
I've done a modification to differentiate KDE / safari<3 / safari>=3. This
to handle bugs with dynamically created styles sheets.
I've found a way to identify Opera event when it hides its window.opera
object. But since I only use this identification to generate statistics on
my sites, and not to handle this browser differently, I don't know if it's
a good idea to publicly reveal it (do you think "webmasters" are still
willfully denying access to Opera?).
I can email you these tests too if you're curious to see them.
regards,
Marc Boucher
| From | Me |
|---|
| To | Marc Boucher |
|---|
| Subject | Re: "browser sniffer" modifications |
|---|
| Date | 22 September 2007 11:30 |
|---|
Marc,
Some interesting changes.
> Gecko and
> IE, which can modify their user-agent string, are placed below detections
> based on the user-agent string. This means that, mainly when gecko is
> spoofing, it can be misidentified.
That is by design. The user agent string cannot be modified using the
browser's menus in a default installation. In fact, the user has to go out
of their way to modify the string, either by manually editing their settings
in about:config, or by installing an extension. If they have gone to that
much trouble, I assume that they have done so for a reason, and I do not
want to prevent them from doing so. Until the setting becomes a part of the
default installation's options dialog or menus, I will keep the script this
way.
In general, I also prefer to have Gecko and IE as the catch-alls at the end,
because I know that authors will ignore my instructions, and will use it to
determine what they consider to be "good" browsers. In those cases, I would
prefer that they catch new or obscure browsers as the browsers they pretend
to be rather than have them as "unknown", where they would be inclined to
block them. Reality can be annoying.
> I'm also using a more efficient way to detect IE (based on
> conditional compilation only supported by MS).
I will not use this invalid nonsense, even if it is reliable. I do not
(currently) want to promote its use. If my opinion of it changes in future,
I may consider changing the approach, but for now, I don't see it happening.
:)
> Just below I place the new detection for gecko. It seems to be the only
> browser to have this type of object:
>
> else if(window.controllers=='[object XULControllers]'){yB[0]='gek'}
Well, this was an interesting one, but I am not sure how much faith I would
put in such a property. Basically, not all geckos use XUL for their chrome.
This could mean that some gecko browser does not support it, and would be
misidentified (though I do not know this for certain).
In addition, it is more of the XUL garbage that Mozilla leaks onto Web page
scripts, when in fact, it should never be exposed to the page at all. Chrome
belongs in chrome, not the Web page. To some extent that is useful since it
means no other browser will implement it unless it uses XUL (which so far
implies gecko, although any other browser is free to implement it on top of
its own engine), but Mozilla may decide to clean up their act and stop
exposing such garbage to the Web page. If they do that, the test stops
working.
> do you think "webmasters" are still willfully denying access to Opera?).
I know for a fact that they do. It still disappoints me to see the ignorance
of Web developers who do it, but they remain a fact of life (in some
countries more than others).
Mark 'Tarquin' Wilton-Jones - author of http://www.howtocreate.co.uk/
| From | Marc Boucher |
|---|
| To | Me |
|---|
| Subject | Re: "browser sniffer" modifications |
|---|
| Date | 22 September 2007 13:50 |
|---|
> If they have
> gone to that much trouble, I assume that they have done so for a reason,
> and I do not want to prevent them from doing so.
I'm not doing this to modify the behavior of my script. But I understand
why you wouldn't want to help those who does, by providing a script.
> Until the setting
> becomes a part of the default installation's options dialog or menus, I
> will keep the script this way.
In my case I using this id to tag script callbacks to the server.
One of my sites loads images from other servers, and I want to know if
browsers have difficulties to load them. I have a script that attach an
event to the DOM nodes and notifies the server when one or more images are
missing. Since this technique doesn't work efficiently in every browser, I
want to know what brand it is.
> I would prefer that they catch new or obscure browsers as the
> browsers they pretend to be rather than have them as "unknown", where
> they would be inclined to block them.
I have kept a copy of the "old" tests in place, in case a browser slips
through. :)
Who knows how newer versions will work ?
> Reality can be annoying.
Yes
>> conditional compilation only supported by MS).
> I will not use this invalid nonsense, even if it is reliable.
:)
> I do not (currently) want to promote its use.
tss tss :)
It's just a comment. ;)
I have only 2 instances of this syntax in use. One for the browser id, and
one to add 'DOMContentLoaded' capability for events in IE. For the rest I
rely on object detection.
> Basically, not all geckos use XUL for
> their chrome. This could mean that some gecko browser does not support
> it, and would be misidentified (though I do not know this for certain).
I use K-Meleon. It doesn't use XUL for its interface, but still has some
XUL elements in use.
But how other browsers handle this?
> To some extent that is
> useful since it means no other browser will implement it unless it uses
> XUL
I hope not. :)
> It still disappoints me to see the
> ignorance of Web developers who do it, but they remain a fact of life
> (in some countries more than others).
More incompetent in some countries than in others?
Most web developers are not developers at all. When you look at the code
they produce...
I always test with as much browsers as possible. It's not that difficult to
install several browsers on the same computer. Even multiple IE (which is
very helpful).
Marc Boucher