You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Mario Ivankovits (JIRA)" <de...@myfaces.apache.org> on 2008/01/19 17:28:34 UTC
[jira] Created: (MYFACES-1805) form stopped working after ajax
request
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.2.0, 1.1.5
Reporter: Mario Ivankovits
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.
[jira] Commented: (MYFACES-1805) form stopped working after ajax
request
Posted by "Stephen Cunliffe (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561338#action_12561338 ]
Stephen Cunliffe commented on MYFACES-1805:
-------------------------------------------
This may be the result of 1 of 2 bugs in IE.
The first, is that you CAN NOT SET THE NAME attribute on ANY element in IE using the DOM Method .setAttribute('name');
(Bug 235)
http://webbugtrack.blogspot.com/2007/10/bug-235-createelement-is-broken-in-ie.html
In this case using forms[formIdx].elements[elemIdx] should work, but it will return undefined if the field was added via JavaScript, and was not added using IE's buggy .createElement(HTMLGarbledStringNotaion)
Also, when trying to retrieve an "item" from any collection/element in IE, it may return the wrong thing. This will happen if you don't specify the .elements part of the path... asking for formObj['action'|'length'|'method'|'target'|'name'] will return the attributes of the form, not the elements in the form.
Its a minor thing, but you need to be extra careful with IE, since it *tries* to return what it *thinks* you want, not necessarily what you've asked for. (see buggy .getElementById() bug and workaround)
(Bug 152)
http://webbugtrack.blogspot.com/2007/08/bug-152-getelementbyid-returns.html
> 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.2.2
>
>
> 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.
[jira] Commented: (MYFACES-1805) form stopped working after ajax
request
Posted by "Simon Kitching (JIRA)" <de...@myfaces.apache.org>.
[ 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.
[jira] Commented: (MYFACES-1805) form stopped working after ajax
request
Posted by "Simon Kitching (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560811#action_12560811 ]
Simon Kitching commented on MYFACES-1805:
-----------------------------------------
Hmm..I just started adding some minor comments to the source to mark this changed as an "ie compatibility hack". But then I looked again.
presume the problem is that this line didn't work without the modification..
context.append("if(typeof form.elements[name]=='undefined')");
But this code looks suspect to me. Where is it stated that the form.elements collection can be indexed using the name *or* id of an element?
According to the w3 spec, HTMLFormElement.elements is just an HTMLCollection type, ie a list not a map:
http://www.w3.org/TR/REC-DOM-Level-1/level-one-html.html#ID-798055546
(search for HTMLFormElement)
In javascript, there are of course no lists so the list is represented as an array that can be indexed using an integer.
But what happens when it is indexed using a non-integer? That seems to me to not be part of the w3 dom spec at all.
I think that the change that Mario made to add the id to the component is good, but that in addition this line of javascript should be changed to be
if (typeof document.getElementById(id)=='undefined')
instead of using the form.elements collection, which is theoretically a list and not a map AFAICT.
The w3schools page also uses this only as a list:
http://w3schools.com/htmldom/coll_form_elements.asp
Comments?
> 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.
[jira] Resolved: (MYFACES-1805) form stopped working after ajax
request
Posted by "Mario Ivankovits (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mario Ivankovits resolved MYFACES-1805.
---------------------------------------
Resolution: Fixed
Fix Version/s: 1.2.2-SNAPSHOT
1.1.6-SNAPSHOT
committed to both myfaces version (1.1, 1.2)
> 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.
[jira] Commented: (MYFACES-1805) form stopped working after ajax
request
Posted by "Martin Marinschek (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561146#action_12561146 ]
Martin Marinschek commented on MYFACES-1805:
--------------------------------------------
Is this related to
https://issues.apache.org/jira/browse/MYFACES-1804
?
regards,
Martin
> 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.