Client-side JavaScript weirdness with assigning a form element -in Windows / IE6 only. Any ideas?

Discussion in 'Javascript' started by Doug Lerner, Jan 21, 2006.

  1. Doug Lerner

    Doug Lerner Guest

    I have this snippet of client side code running:

    var makeField = document.forms[0][makeFieldName];

    alert("makeFieldName name,length,type=" + makeFieldName + ", " +
    makeField.name + "," + makeField.length + "," + makeField.type);


    The alert is just in there for debugging.

    The function containing this code is called when a select field option is
    changed. makeFieldName is the name of the select field in the form.

    It works correctly from:

    OS X / Safari
    OS X / IE
    OS X / Firefox
    Windows / Firefox

    but doesn't work right in Windows / IE6.

    The diagnostic alert that shows up from all the browsers except Windows /
    IE6 is the same:

    makeFieldName name,length,type=1_onlyCarMake, 1_onlyCarMake,63,select-one

    In other words, the makeFieldName is correct (1_onlyCarMake), and is the
    same as makeField.name. The correct field is found and it has the right
    number of options and the correct type for a select field.

    But in Windows / IE6 only the diagnostic alert shows up with:

    makeFieldName name,length,type=1_onlyCarMake, startWith,undefined,hidden

    The startWith field happens to be the first field in that form (the only
    form in the document, by the way) and it is, in fact, a hidden field. Thus
    it makes sense that the length shown is undefined, since it is not a select
    field and thus has no options array.

    The problem is - why is Windows /IE6 incorrectly returning that field as a
    result of the expression "document.forms[0][makeFieldName]" when all the
    other browsers are returning the correct field?

    It doesn't make any different whether I use document.forms[0][makeFieldName]
    or actually specify the name of the form, as in
    document["thisFormName"][makeFieldName]. In either case it works everywhere
    but in Windows / IE6.

    Anybody have any idea why the client is confused and returning the first
    form element rather than the named one?

    Thanks!

    doug
    Doug Lerner, Jan 21, 2006
    #1
    1. Advertising

  2. Doug Lerner

    Doug Lerner Guest

    Re: Client-side JavaScript weirdness with assigning a formelement - in Windows / IE6 only. Any ideas?

    I fixed it! It's definitely a weird Windows-only IE-only bug.

    Another staff member had taken part of my code and transplanted it. When she
    did this she created a couple of rather strange-looking identifiers that I
    never would have made, like "1_onlyCarMake, starting with an integer.

    Those are illegal JavaScript identifiers if they are used in the
    dot.notation syntax. But they *should* be perfectly legal if used in the
    associative array syntax (in quotes, in square brackets), which we were
    doing.

    It was fine in all the browsers except Windows / IE6 choked on them.

    When I changed the identifiers to something that didn't start with an
    integer, like onlyCar1Make, it all worked in all browsers.

    Just something to be aware of when coding for Windows / IE!

    doug


    On 1/21/06 12:41 PM, in article BFF7DC8E.1C878%, "Doug
    Lerner" <> wrote:

    > I have this snippet of client side code running:
    >
    > var makeField = document.forms[0][makeFieldName];
    >
    > alert("makeFieldName name,length,type=" + makeFieldName + ", " +
    > makeField.name + "," + makeField.length + "," + makeField.type);
    >
    >
    > The alert is just in there for debugging.
    >
    > The function containing this code is called when a select field option is
    > changed. makeFieldName is the name of the select field in the form.
    >
    > It works correctly from:
    >
    > OS X / Safari
    > OS X / IE
    > OS X / Firefox
    > Windows / Firefox
    >
    > but doesn't work right in Windows / IE6.
    >
    > The diagnostic alert that shows up from all the browsers except Windows /
    > IE6 is the same:
    >
    > makeFieldName name,length,type=1_onlyCarMake, 1_onlyCarMake,63,select-one
    >
    > In other words, the makeFieldName is correct (1_onlyCarMake), and is the
    > same as makeField.name. The correct field is found and it has the right
    > number of options and the correct type for a select field.
    >
    > But in Windows / IE6 only the diagnostic alert shows up with:
    >
    > makeFieldName name,length,type=1_onlyCarMake, startWith,undefined,hidden
    >
    > The startWith field happens to be the first field in that form (the only
    > form in the document, by the way) and it is, in fact, a hidden field. Thus
    > it makes sense that the length shown is undefined, since it is not a select
    > field and thus has no options array.
    >
    > The problem is - why is Windows /IE6 incorrectly returning that field as a
    > result of the expression "document.forms[0][makeFieldName]" when all the
    > other browsers are returning the correct field?
    >
    > It doesn't make any different whether I use document.forms[0][makeFieldName]
    > or actually specify the name of the form, as in
    > document["thisFormName"][makeFieldName]. In either case it works everywhere
    > but in Windows / IE6.
    >
    > Anybody have any idea why the client is confused and returning the first
    > form element rather than the named one?
    >
    > Thanks!
    >
    > doug
    >
    >
    Doug Lerner, Jan 21, 2006
    #2
    1. Advertising

  3. Re: Client-side JavaScript weirdness with assigning a form element - in Windows / IE6 only. Any ideas?

    Digital wrote:
    > Be careful relying on this implementation.


    It has often been observed that individuals who top-post to Usenet show
    evidence of not actually reading the messages that they are responding
    to. In this case I suspect that the (minimal) discipline of creating a
    well-formed Usenet post, with responses following trimmed quotes of
    preceding messages that provide the context for the response, would have
    avoided your posting an essentially irrelevant response.

    > What you are running into in IE6 is not a bug, rather you
    > may consider it compliance with standards. Browsers are
    > becoming more and more standards compliant. When the
    > aforementioned browsers conform to Item 7.6 in the ECMAScript
    > Language Specification your code will no longer work in
    > those browsers.

    <snip>

    However:-

    > Doug Lerner wrote:

    <snip>
    >> Those are illegal JavaScript identifiers if they are used in
    >> the dot.notation syntax. But they *should* be perfectly legal
    >> if used in the associative array syntax (in quotes, in square
    >> brackets), which we were doing.

    <snip>

    - so the applicable section of ECMA 262 is section 11.2.1, where the
    production rules and algorithms for the bracket notation property
    accessor make it clear that ECMAScript places no restrictions upon the
    sequences of characters that may be used as the property names of
    object, and accessed with bracket notation.

    The correspondence of a property name with an Identifier is only
    significant for dot notation property accessors.

    Richard.
    Richard Cornford, Jan 21, 2006
    #3
  4. Re: Client-side JavaScript weirdness with assigning a form element- in Windows / IE6 only. Any ideas?

    "Richard Cornford" <> writes:

    > - so the applicable section of ECMA 262 is section 11.2.1, where the
    > production rules and algorithms for the bracket notation property
    > accessor make it clear that ECMAScript places no restrictions upon the
    > sequences of characters that may be used as the property names of
    > object, and accessed with bracket notation.


    Very true. While I thought I had understood this, it was still
    something of an experience when I realised that the empty string
    was a valid property name :)

    var x = {};
    x[""] = 42;
    alert(x[""]);

    Well, I think it's cute. :)
    /L
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, Jan 21, 2006
    #4
  5. Doug Lerner

    Doug Lerner Guest

    Re: Client-side JavaScript weirdness with assigning a formelement - in Windows / IE6 only. Any ideas?

    I did mention in my note that I changed the identifier.

    But isn't what you are saying only true with respect to actual identifiers?

    If you are using the associative array syntax it shouldn't matter because
    properties are really only associative array elements.

    So while

    a.1_something

    is definitely not legal,

    a["1_something"]

    is perfectly legal.

    What is inside brackets does not have to be a "legal indentifier". In fact,
    that is one purpose of having that notation (the other being able to have
    dynamically named properties).

    That's why I think it is a bug for IE6 not to recognize that.

    doug



    On 1/22/06 4:05 AM, in article JBvAf.40747$-kc.rr.com,
    "Digital" <> wrote:

    > Be careful relying on this implementation. What you are running into in IE6
    > is not a bug, rather you may consider it compliance with standards.
    > Browsers are becoming more and more standards compliant. When the
    > aforementioned browsers conform to Item 7.6 in the ECMAScript Language
    > Specification your code will no longer work in those browsers.
    >
    > An identifier is described as:
    >
    > IdentifierStart::
    > UnicodeLetter
    > $
    > _
    > \ UnicodeEscapeSequence
    >
    > A NumberLiteral does not conform to this standard. The reason for this is
    > demonstrated more clearly in section 7.8.3 while defining HexIntegerLiteral.
    > It states:
    >
    > "The source character immediately following a NumberLiteral must not be an
    > IdentifierStart or DecimalDigit."
    >
    > The browsers in which your code works are ignoring the IdentifierStart
    > definition and holding to wording in 7.8.3 to imply that any characters
    > directly following a NumberLiteral must be part of an Identifier because an
    > IdentifierStart may not immediately follow a NumberLiteral. The biggest
    > drawback to this interpretation is going to be in the debugging arena. The
    > debugging will not be as accurate or as informative. More than likely this
    > will be realized by the browser authors and the code in question will no
    > longer be valid. If you continue to code in this manner may I suggest that
    > you declare all your variables with the 'var' statement. This will not keep
    > your code from breaking should the standard be adopted. However it will
    > make your debugging experience much more efficient and enjoyable.
    >
    > ~Digital~
    >
    >
    > "Doug Lerner" <> wrote in message
    > news:BFF801EB.1C994%...
    >> I fixed it! It's definitely a weird Windows-only IE-only bug.
    >>
    >> Another staff member had taken part of my code and transplanted it. When
    >> she
    >> did this she created a couple of rather strange-looking identifiers that I
    >> never would have made, like "1_onlyCarMake, starting with an integer.
    >>
    >> Those are illegal JavaScript identifiers if they are used in the
    >> dot.notation syntax. But they *should* be perfectly legal if used in the
    >> associative array syntax (in quotes, in square brackets), which we were
    >> doing.
    >>
    >> It was fine in all the browsers except Windows / IE6 choked on them.
    >>
    >> When I changed the identifiers to something that didn't start with an
    >> integer, like onlyCar1Make, it all worked in all browsers.
    >>
    >> Just something to be aware of when coding for Windows / IE!
    >>
    >> doug
    >>
    >>
    >> On 1/21/06 12:41 PM, in article BFF7DC8E.1C878%, "Doug
    >> Lerner" <> wrote:
    >>
    >>> I have this snippet of client side code running:
    >>>
    >>> var makeField = document.forms[0][makeFieldName];
    >>>
    >>> alert("makeFieldName name,length,type=" + makeFieldName + ", " +
    >>> makeField.name + "," + makeField.length + "," + makeField.type);
    >>>
    >>>
    >>> The alert is just in there for debugging.
    >>>
    >>> The function containing this code is called when a select field option is
    >>> changed. makeFieldName is the name of the select field in the form.
    >>>
    >>> It works correctly from:
    >>>
    >>> OS X / Safari
    >>> OS X / IE
    >>> OS X / Firefox
    >>> Windows / Firefox
    >>>
    >>> but doesn't work right in Windows / IE6.
    >>>
    >>> The diagnostic alert that shows up from all the browsers except Windows /
    >>> IE6 is the same:
    >>>
    >>> makeFieldName name,length,type=1_onlyCarMake, 1_onlyCarMake,63,select-one
    >>>
    >>> In other words, the makeFieldName is correct (1_onlyCarMake), and is the
    >>> same as makeField.name. The correct field is found and it has the right
    >>> number of options and the correct type for a select field.
    >>>
    >>> But in Windows / IE6 only the diagnostic alert shows up with:
    >>>
    >>> makeFieldName name,length,type=1_onlyCarMake, startWith,undefined,hidden
    >>>
    >>> The startWith field happens to be the first field in that form (the only
    >>> form in the document, by the way) and it is, in fact, a hidden field.
    >>> Thus
    >>> it makes sense that the length shown is undefined, since it is not a
    >>> select
    >>> field and thus has no options array.
    >>>
    >>> The problem is - why is Windows /IE6 incorrectly returning that field as
    >>> a
    >>> result of the expression "document.forms[0][makeFieldName]" when all the
    >>> other browsers are returning the correct field?
    >>>
    >>> It doesn't make any different whether I use
    >>> document.forms[0][makeFieldName]
    >>> or actually specify the name of the form, as in
    >>> document["thisFormName"][makeFieldName]. In either case it works
    >>> everywhere
    >>> but in Windows / IE6.
    >>>
    >>> Anybody have any idea why the client is confused and returning the first
    >>> form element rather than the named one?
    >>>
    >>> Thanks!
    >>>
    >>> doug
    >>>
    >>>

    >>

    >
    >
    Doug Lerner, Jan 22, 2006
    #5
  6. Re: Client-side JavaScript weirdness with assigning a form element - in Windows / IE6 only. Any ideas?

    Digital wrote:
    <snip>
    > Section 11.2.1 makes one explicit statement about Identifiers
    > and identifier-strings:
    >
    > "where <indentifier-string> is a string literal containing
    > the same sequence of characters as the Identifier."


    You are reading too much into what is actually an explanatory text. That
    section is explaining that when a bracket notation property accessor
    uses exactly the same character sequence as the property name as a dot
    notation property accessor their behaviour is identical. In order to
    express the equivalence in behaviour it is necessary for the bracket
    notation property accessor to use a property name that is an Identifier
    because that restriction applies to dot notation.

    This allows the specification to define actual behaviour of property
    accessors with a single algorithm and leave the production rules for dot
    notation to imply the additional restriction upon the token following
    the dot.

    The specified productions for bracket notation property accessors are:-

    MemberExpression [ Expression ]
    CallExpression [ Expression ]

    - and '<identifier-string>' is not a defined component of the language
    at all (it does not appear in appendix A).

    > Section 11.2.1 is the only section in the specificiation that
    > makes mention of identifier-strings.


    And only in an explanation of behaviour.

    > Therefore Section 11.2.1 should be taken literally to mean
    > that the indentifier-string in bracket notation should
    > contain the same sequence of characters as if the
    > identifier-string were to be used as an Identifier as there
    > are no other ECMA 262 rules that can take precedence.


    The algorithm actually takes precedence:-

    <quote cite="ECMA 262, 3rd ed. section 11.2.1">
    The production MemberExpression : MemberExpression [ Expression ] is
    evaluated as follows:

    1. Evaluate MemberExpression.
    2. Call GetValue(Result(1)).
    3. Evaluate Expression.
    4. Call GetValue(Result(3)).
    5. Call ToObject(Result(2)).
    6. Call ToString(Result(4)).
    7. Return a value of type Reference whose base object is Result(5)
    and whose property name is Result(6).

    The production CallExpression : CallExpression [ Expression ] is
    evaluated in exactly the same manner, except that the contained
    CallExpression is evaluated in step 1.
    </quote>

    Where we find no examination of the nature of the string that will stand
    as the object's property name. If any restriction were intended it would
    have to be applied in that algorithm, and after the evaluation of the
    Expression within the brackets.

    > To mazimize the life of code written one should comply.


    No such restriction applies so complying with it is unnecessary. It is
    also practically impossible to comply because the 'array index' members
    of an array can only be accessed by bracket notation property accessors
    (the specification contains no alternative mechanism), and an 'array
    index' cannot qualify as an Identifier.

    > Again, this is most important when it comes to creating and
    > using debuggers ...

    <snip>

    As the '<Identifier string>' premise is false this debugger
    consideration is likely a red herring.

    > Richard Cornford" <Richard...

    <snip>

    Please do not top-post to comp.lang.javascript. Even if you do not care
    for the long established Usenet conventions your example has potential
    to do harm to others.

    Richard.
    Richard Cornford, Jan 22, 2006
    #6
    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. Shaul Feldman
    Replies:
    0
    Views:
    830
    Shaul Feldman
    Apr 16, 2004
  2. steve
    Replies:
    4
    Views:
    510
    Brian van den Broek
    Mar 13, 2005
  3. Replies:
    1
    Views:
    1,017
    cwdjrxyz
    Nov 29, 2006
  4. Steve
    Replies:
    3
    Views:
    125
    Steve
    Sep 15, 2006
  5. Rob

    Multiple form weirdness in IE6

    Rob, Jan 31, 2008, in forum: Javascript
    Replies:
    3
    Views:
    101
Loading...

Share This Page