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

[Doug Lerner]

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]

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 BF*****************@lerner.net, "Doug
Lerner" <do**@lerner.net> 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

[Jasen Betts]

On 2006-01-21, Doug Lerner <do**@lerner.net> wrote:

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

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

possibly the digit at the start of the name is confusing it.

Bye.
Jasen

[Digital]

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" <do**@lerner.net> wrote in message
news:BFF801EB.1C994%do**@lerner.net...

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%do**@lerner.net, "Doug
Lerner" <do**@lerner.net> 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

[Richard Cornford]

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.

[Lasse Reichstein Nielsen]

"Richard Cornford" <Ri*****@litotes.demon.co.uk> 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 - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Digital]

Richard -

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

Section 11.2.1 is the only section in the specificiation that makes mention
of identifier-strings. 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.
To mazimize the life of code written one should comply.

Again, this is most important when it comes to creating and using debuggers
as object-model trees currently depend on dot-notation. By using an
identifier-string that represents an illegal identifier you are forced to
hand-type each element you wish to watch instead of being able to navigate
via point and click. This becomes even more cumbersome when using a
debugger like Venkmann that does not allow inline editing of watch
statements but rather forces the developer to always add a new statement.

~Digital~

"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:dq*******************@news.demon.co.uk...

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.

[Doug Lerner]

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 JB******************@tornado.rdc-kc.rr.com,
"Digital" <re****@spam.com> 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" <do**@lerner.net> wrote in message
news:BFF801EB.1C994%do**@lerner.net...

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%do**@lerner.net, "Doug
Lerner" <do**@lerner.net> 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

[Richard Cornford]

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.