[ 
https://issues.apache.org/jira/browse/MYFACES-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560830#action_12560830
 ] 

Simon Kitching commented on MYFACES-1805:
-----------------------------------------

Ok, I have found a section in the w3 specs that say that indexing using 
square-bracket notation is ok. This doc here:
  http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html
says:

Functions of objects that implement the HTMLCollection interface:

    item(index)
        This function returns an object that implements the Node interface.
        The index parameter is a Number.
        Note: This object can also be dereferenced using square bracket 
notation (e.g. obj[1]). Dereferencing with an integer index is equivalent to 
invoking the item function with that index.
    namedItem(name)
        This function returns an object that implements the Node interface.
        The name parameter is a String.
        Note: This object can also be dereferenced using square bracket 
notation (e.g. obj["foo"]). Dereferencing using a string index is equivalent to 
invoking the namedItem function with that index.

So the only problem is that the namedItem function in IE does not return input 
elements with that name. And the only fix for that is exactly the code 
committed - except that the javascript props really should be renamed too, to 
reflect that lookup-by-id is now happening, not lookup-by-name. Hardly worth 
changing though.

Interestingly, I see that in the whatwg draft for html5, they have in the 
HTMLCollection class def:
The namedItem(key) method must return the first node in the collection that 
matches the following requirements:
    * It is an a, applet, area, form, img, or object element with a name 
attribute equal to key, or,
    * It is an HTML element of any kind with an id attribute equal to key.

My guess is that they are specifying it that weird way in order to be 
backwards-compatible with exactly this IE bug...


> form stopped working after ajax request
> ---------------------------------------
>
>                 Key: MYFACES-1805
>                 URL: https://issues.apache.org/jira/browse/MYFACES-1805
>             Project: MyFaces Core
>          Issue Type: Bug
>    Affects Versions: 1.1.5,  1.2.0
>            Reporter: Mario Ivankovits
>             Fix For:  1.1.6-SNAPSHOT, 1.2.2-SNAPSHOT
>
>
> In a little bit complicated form using multiple PPR areas the datascroller 
> attached to a datatable stopped working with InternetExplorer after the first 
> ajax request.
> MyFaces always sent the current page again.
> It turned out that the code in oamSetHiddenInput is not fully compatible with 
> InternetExplorer.
> The problem is that even after adding the element to the form using 
> javascript the check for it (typeof form.elements[name]=='undefined') still 
> returns undefined.
> After setting the id of the created element (beside of it's name) fixed this 
> problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to