Site Navigation

Showing posts with label Name Attribute. Show all posts
Showing posts with label Name Attribute. Show all posts

Thursday, October 29, 2009

bug 361 - Anchors collection in IE contains invalid members

Issue: #361
Affects: IE6, IE7, IE8

In the days before the DOM Methods we have today we only had access to a few special collections for things like forms, anchors, links, images, etc.

They may not be as sexy as document.getElementById(), but they worked, and still do to this day... and depending what you are trying to access may actually be much quicker and easier.

So to the point, the document.anchors collection contains an array of all the anchors defined in the page.

Anchors by definition are <a> tags with a name attribute specified.

Now for the bug.

As disclosed in (bug 152) IE has notoriously had issues with differentiating between id and name attributes, polluting IDs with NAMEs and vica versa.

Thus, if you have hyperlinks with an id attribute set in IE... you will now have a new member in the document.anchors collection even though there is no name attribute specified! Have lots of links with id attributes set? Then you have lots of extra items in your document.anchors collection.

Of course the interesting twist on this is that in modern browsers, any element (div, table, span, img) with an id attribute set can act "like" an anchor in that you can add it as a hash tag in the URL to auto-scroll to a specific spot however keep in mind that by definition only an <a> tag with a name attribute set is a valid element in the document.anchors collection.


Known Workarounds: None.



Related Issues: None.


Bug/Site Feedback |
Submit a bug

Tuesday, May 13, 2008

bug 326 - field names in IE that break with Mootools

Issue: #326
Affects: IE6, IE7, IE8 Beta 1?
JS Library: Mootools
Mootools Trac#:798

The following fields (name or id) will cause issues in Mootools:

"addEvent", "match", "position", "search"

Due to conflicts when the name exists in Element.Prototype, it will cause issues.

Example:
These will fail when you try to iterate using .each (for example) over a form element array.

<input id="addEvent"/>
<input id="match"/>
<input id="position"/>
<input id="search"/>

<input name="addEvent"/>
<input name="match"/>
<input name="position"/>
<input name="search"/>



Known Workarounds: None. (other than to be careful not to use these field identifiers)


Related Issues: None.

Bug/Site Feedback |
Submit a bug

Wednesday, April 16, 2008

bug 403 - another getElementsByName() bugs in IE

Issue: #403
Affects: IE6, IE7
Fixed in: IE8 Beta 2


Related to (bug 411), another bug with getElementsByName( name ); has been noted.

If you dynamically change the name attribute of an element (e.g. an input box) it will affect the form submission, but in IE it won't actually change the name attribute. See these bugs: (bug 199), (bug 235), (bug 237), (bug 240) & (bug 242)

What this also means, is that in IE, if you try to retrieve the elements you have renamed, you will not be able to retrieve them.

Example:

<script type="text/javascript">
var myElem = document.forms[0].elements['oldname'];
myElem.name = 'newname';//can't use .setAttribute() due to another IE bug

//how many elements with the name 'newname' do we now have?
alert(document.getElementsByName('newname').length + ' elements found!');
</script>


In IE, this will alert ZERO.


Known Workarounds: None.



Related Issues: None.

Bug/Site Feedback |
Submit a bug

Wednesday, March 19, 2008

bug 366 - we call a rose by any other name would... IE JS Error?

Issue: #366
Affects: IE6, IE7

"What's in a name? That which we call a rose by any other name would smell as sweet."
- William Shakespear (Romeo and Juliet, Act II, Sc. II)


Have you ever tried to rename an input field with JavaScript just before submitting a form? Quite likely, and it works just fine... or does it?

There are times when renaming a field is easier than deleting and inserting a new one. When such a time arises, a simple:

Example:

<script type="text/javascript">
document.forms[0].elements['rose'].name = 'flower';
</script>


Will work just fine. When you submit the page, the parameter on the GET/POST request/submission will be called "flower".

However if you plan to use JavaScript to re-access that field in IE (e.g. to perform some client side field validation), don't try to access it by name! It will work in all browsers except Internet Explorer.


Known Workarounds: None.



Related Issues: (bug 152), (bug 162), (bug 235), (bug 237), (bug 240), (bug 242), (bug 411).

Bug/Site Feedback |
Submit a bug

Sunday, March 2, 2008

bug 240 - setAttribute "name" is half broken in IE

Issue: #240
Affects: IE6, IE7

Setting the name attribute of an element in IE is complicated at best (bug 242). Using .setAttribute('name', 'someValue'); will fail in IE. The name attribute is ~readonly~ and can't be modified. However interestingly enough, if you do set this, if the name was applied to a form field, IE will send the correct parameter name on the POST/GET request.

It is highly recommended that you apply some version of the (bug 235) workaround to avoid this bug in IE.


Known Workarounds: One. Use the hack in bug 235.



Related Issues: (bug 242), (bug 235)

Bug/Site Feedback |
Submit a bug

Friday, August 24, 2007

bug 152 - getElementById returns incorrect objects in IE and Opera

Issue: #152
Affects: IE5, IE5.5, IE6, IE7, Opera 8.2, Opera 9.2
Fixed in: Opera 9.50 alpha 1 build 9500
Almost Fixed in: IE8 Beta 1
Fixed in: IE8 Beta 2

MSIE Feedback ID: 333979

Example:
<script type="text/javascript">
var descField = document.getElementById( 'description' );
alert( descField.nodeName );
</script>

The above code works perfectly, in all browsers returning the element with the id "description". Well almost. IE will return the element with that id, but it will also return any element with a name set to "description". At first glance this may not seem such an issue, but consider this; Do you have a meta tag on any of your pages? Do any of them have a name attribute with the value description? If so, you will get a reference to the meta tag, not the form element (or whatever you thought you were getting, as indicated in the spec for getElementById).

When you think for a moment, about where the name attribute is set, this becomes rather scary. Any named anchor, can now conflict with your well defined element ids.

Notes:
So you might ask, why is this broken in Opera? Opera is usually pretty good at supporting the specs! Well, it seems that for maximum compatibility with IE, even though it is implemented wrong, they mimicked the broken behavior.


Known Workarounds: No direct methods, using Option #3 below is suggested.

Workaround Option: 1
If you rely heavily on getElementById, and you suspect that you may have name conflicts, or that user specific content added to a page may cause conflicts you can use getElementsByTagName( tagName ) then iterate over the results and compare the value returned by getAttribute( 'id' ).

Example Workaround Code:
var inputs = document.getElementsByTagName( 'textarea' );
var descField = null;
for(var i=0;i<inputs.length;i++){
if(inputs.item(i).getAttribute( 'id' ) == 'description' ){
descField = inputs.item(i);
break;
}
}




Workaround Option: 2
If you have the ability to globally apply fixes for IE and Opera, the following code will make both of them follow the spec to a 'T', with a very tiny performance hit.

In this example, we redifine the getElementById method, to work as it was intended.
Example Workaround Code:
//use browser sniffing to determine if IE or Opera (ugly, but required)
var isOpera, isIE = false;
if(typeof(window.opera) != 'undefined'){isOpera = true;}
if(!isOpera && navigator.userAgent.indexOf('Internet Explorer')){isIE = true;}

//fix both IE and Opera (adjust when they implement this method properly)
if(isOpera || isIE){
document.nativeGetElementById = document.getElementById;
//redefine it!
document.getElementById = function(id){
var elem = document.nativeGetElementById(id);
if(elem){
//verify it is a valid match!
if(elem.id == id){
//valid match!
return elem;
} else {
//not a valid match!
//the non-standard, document.all array has keys for all name'd, and id'd elements
//start at one, because we know the first match, is wrong!
for(var i=1;i<document.all[id].length;i++){
if(document.all[id][i].id == id){
return document.all[id][i];
}
}
}
}
return null;
};
}



Oh my! this just gets better and better! (after posting and using this I noted (as did J. Max Wilson) that the second workaround, actually exposes another bug in IE!

Third time's a charm (we hope!)

Workaround Option: 3

Same as workaround 2 above, but rather than test elem.id or elem.getAttribute('id') we'll use the much safer elem.attributes collection. Unfortunately if the element you are looking for, in turn has a child element with a name or id attribute, that is set to "id", it will not test the attribute, but rather the child element. (bug 162 - global namespace pollution)

Example Workaround Code:
//use browser sniffing to determine if IE or Opera (ugly, but required)
var isOpera, isIE = false;
if(typeof(window.opera) != 'undefined'){isOpera = true;}
if(!isOpera && navigator.userAgent.indexOf('Internet Explorer')){isIE = true;}

//fix both IE and Opera (adjust when they implement this method properly)
if(isOpera || isIE){
document.nativeGetElementById = document.getElementById;
//redefine it!
document.getElementById = function(id){
var elem = document.nativeGetElementById(id);
if(elem){
//verify it is a valid match!
if(elem.attributes['id'] && elem.attributes['id'].value == id){
//valid match!
return elem;
} else {
//not a valid match!
//the non-standard, document.all array has keys for all name'd, and id'd elements
//start at one, because we know the first match, is wrong!
for(var i=1;i<document.all[id].length;i++){
if(document.all[id][i].attributes['id'] && document.all[id][i].attributes['id'].value == id){
return document.all[id][i];
}
}
}
}
return null;
};
}




Related Issues: (bug 154), (bug 411), (bug 162).