You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Thomas Fischer (JIRA)" <de...@myfaces.apache.org> on 2008/01/16 13:36:35 UTC
[jira] Created: (MYFACES-1804) Pressing a download button corrupts
other button actions in Internet Explorer
Pressing a download button corrupts other button actions in Internet Explorer
-----------------------------------------------------------------------------
Key: MYFACES-1804
URL: https://issues.apache.org/jira/browse/MYFACES-1804
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.2.0
Environment: Microsoft internet Explorer 6.0 (not tested for other versions)
Reporter: Thomas Fischer
Situation: The user accesses a jsf page where a commandlink or commandButton starts a download, and other commandLinks or CommandButtons are present in the same form, using the internet explorer as a browser. The user e clicks on the download Button. Afterwards, the user clicks on any other button in the same form.
Observed behaviour: The previous download is started again, regardless of the action associated with the button
Expected behaviour: The action associated with the button should be executed
Analysis: The error originates in the generated javascript function oamSetHiddenInput(formname, name, value). In this function, it is checked whether the hidden input already exists, using the javascript code
if(typeof form.elements[name]=='undefined')
This works fine in the Internet explorer as long as the hidden input was created in html. If the hidden input was created using javascript, e.g. by the code in the same function, the above condition returns true although the hidden input already exists. This results in creating a second hidden input field instead of replacing the value in the existing one. If the server only uses the value of the first(i.e. already existing) hidden input field, it gets the old value instead of the new one. In the end, myfaces reads the old value of the html parameter ${formName}:_idcl, and so the old action is executed instead of the new one.
Resolution: Accessing the hidden input via indices (form.elements[0], form.elements[1] ...) also works if the hidden input is created dynamically.
Note that the error does only occur if the page is not reloaded when the first button is pressed, so a special action as e.g. a download is needed to trigger the behaviour.
I'd consider this to be a bug in IE, but as we cannot persuade all users to use a browser which is less buggy, a workaround should be implemented in myfaces. The error does not occur in Firefox.
As the implementation is in the myfaces_shared project, this affects both core and tomahawk.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1804) Pressing a download button corrupts
other button actions in Internet Explorer
Posted by "Mario Ivankovits (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mario Ivankovits updated MYFACES-1804:
--------------------------------------
Resolution: Duplicate
Status: Resolved (was: Patch Available)
It is so strange.
Two bugs uncovered by different people and filed in sequence. I can't belive it :-) Way too cool.
MYFACES-1805 fixed it.
> Pressing a download button corrupts other button actions in Internet Explorer
> -----------------------------------------------------------------------------
>
> Key: MYFACES-1804
> URL: https://issues.apache.org/jira/browse/MYFACES-1804
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
> Affects Versions: 1.2.0
> Environment: Microsoft internet Explorer 6.0 (not tested for other versions)
> Reporter: Thomas Fischer
> Attachments: myfaces-1804.patch, testHiddenInputJavascript.html, testie.jsp, TestieController.java
>
>
> Situation: The user accesses a jsf page where a commandlink or commandButton starts a download, and other commandLinks or CommandButtons are present in the same form, using the internet explorer as a browser. The user e clicks on the download Button. Afterwards, the user clicks on any other button in the same form.
> Observed behaviour: The previous download is started again, regardless of the action associated with the button
> Expected behaviour: The action associated with the button should be executed
> Analysis: The error originates in the generated javascript function oamSetHiddenInput(formname, name, value). In this function, it is checked whether the hidden input already exists, using the javascript code
> if(typeof form.elements[name]=='undefined')
> This works fine in the Internet explorer as long as the hidden input was created in html. If the hidden input was created using javascript, e.g. by the code in the same function, the above condition returns true although the hidden input already exists. This results in creating a second hidden input field instead of replacing the value in the existing one. If the server only uses the value of the first(i.e. already existing) hidden input field, it gets the old value instead of the new one. In the end, myfaces reads the old value of the html parameter ${formName}:_idcl, and so the old action is executed instead of the new one.
> Resolution: Accessing the hidden input via indices (form.elements[0], form.elements[1] ...) also works if the hidden input is created dynamically.
> Note that the error does only occur if the page is not reloaded when the first button is pressed, so a special action as e.g. a download is needed to trigger the behaviour.
> I'd consider this to be a bug in IE, but as we cannot persuade all users to use a browser which is less buggy, a workaround should be implemented in myfaces. The error does not occur in Firefox.
> As the implementation is in the myfaces_shared project, this affects both core and tomahawk.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1804) Pressing a download button
corrupts other button actions in Internet Explorer
Posted by "Thomas Fischer (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559862#action_12559862 ]
Thomas Fischer commented on MYFACES-1804:
-----------------------------------------
I am not sure what they mean at Web Bug Track bug 235 with "it will "appear" to work, until you submit the page". In myfaces, the form is submitted via javascript, and the hidden parameter _IS_ transferred to the server. So the only problem is that the hidden input is not accessible by name.
I am not sure what is more desirable, a browser switch or the performance penalty by a browser independent implementation, but in my opinion both are good solutions to the problem.
> Pressing a download button corrupts other button actions in Internet Explorer
> -----------------------------------------------------------------------------
>
> Key: MYFACES-1804
> URL: https://issues.apache.org/jira/browse/MYFACES-1804
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
> Affects Versions: 1.2.0
> Environment: Microsoft internet Explorer 6.0 (not tested for other versions)
> Reporter: Thomas Fischer
> Attachments: myfaces-1804.patch, testHiddenInputJavascript.html, testie.jsp, TestieController.java
>
>
> Situation: The user accesses a jsf page where a commandlink or commandButton starts a download, and other commandLinks or CommandButtons are present in the same form, using the internet explorer as a browser. The user e clicks on the download Button. Afterwards, the user clicks on any other button in the same form.
> Observed behaviour: The previous download is started again, regardless of the action associated with the button
> Expected behaviour: The action associated with the button should be executed
> Analysis: The error originates in the generated javascript function oamSetHiddenInput(formname, name, value). In this function, it is checked whether the hidden input already exists, using the javascript code
> if(typeof form.elements[name]=='undefined')
> This works fine in the Internet explorer as long as the hidden input was created in html. If the hidden input was created using javascript, e.g. by the code in the same function, the above condition returns true although the hidden input already exists. This results in creating a second hidden input field instead of replacing the value in the existing one. If the server only uses the value of the first(i.e. already existing) hidden input field, it gets the old value instead of the new one. In the end, myfaces reads the old value of the html parameter ${formName}:_idcl, and so the old action is executed instead of the new one.
> Resolution: Accessing the hidden input via indices (form.elements[0], form.elements[1] ...) also works if the hidden input is created dynamically.
> Note that the error does only occur if the page is not reloaded when the first button is pressed, so a special action as e.g. a download is needed to trigger the behaviour.
> I'd consider this to be a bug in IE, but as we cannot persuade all users to use a browser which is less buggy, a workaround should be implemented in myfaces. The error does not occur in Firefox.
> As the implementation is in the myfaces_shared project, this affects both core and tomahawk.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1804) Pressing a download button corrupts
other button actions in Internet Explorer
Posted by "Thomas Fischer (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Fischer updated MYFACES-1804:
------------------------------------
Status: Patch Available (was: Open)
> Pressing a download button corrupts other button actions in Internet Explorer
> -----------------------------------------------------------------------------
>
> Key: MYFACES-1804
> URL: https://issues.apache.org/jira/browse/MYFACES-1804
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
> Affects Versions: 1.2.0
> Environment: Microsoft internet Explorer 6.0 (not tested for other versions)
> Reporter: Thomas Fischer
> Attachments: testHiddenInputJavascript.html
>
>
> Situation: The user accesses a jsf page where a commandlink or commandButton starts a download, and other commandLinks or CommandButtons are present in the same form, using the internet explorer as a browser. The user e clicks on the download Button. Afterwards, the user clicks on any other button in the same form.
> Observed behaviour: The previous download is started again, regardless of the action associated with the button
> Expected behaviour: The action associated with the button should be executed
> Analysis: The error originates in the generated javascript function oamSetHiddenInput(formname, name, value). In this function, it is checked whether the hidden input already exists, using the javascript code
> if(typeof form.elements[name]=='undefined')
> This works fine in the Internet explorer as long as the hidden input was created in html. If the hidden input was created using javascript, e.g. by the code in the same function, the above condition returns true although the hidden input already exists. This results in creating a second hidden input field instead of replacing the value in the existing one. If the server only uses the value of the first(i.e. already existing) hidden input field, it gets the old value instead of the new one. In the end, myfaces reads the old value of the html parameter ${formName}:_idcl, and so the old action is executed instead of the new one.
> Resolution: Accessing the hidden input via indices (form.elements[0], form.elements[1] ...) also works if the hidden input is created dynamically.
> Note that the error does only occur if the page is not reloaded when the first button is pressed, so a special action as e.g. a download is needed to trigger the behaviour.
> I'd consider this to be a bug in IE, but as we cannot persuade all users to use a browser which is less buggy, a workaround should be implemented in myfaces. The error does not occur in Firefox.
> As the implementation is in the myfaces_shared project, this affects both core and tomahawk.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1804) Pressing a download button
corrupts other button actions in Internet Explorer
Posted by "Stephen Cunliffe (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559800#action_12559800 ]
Stephen Cunliffe commented on MYFACES-1804:
-------------------------------------------
A few notes.
1.) This will affect IE6 and IE7.
2.) The bug is well documented over on Web Bug Track, including a solution to create the elements with a name attribute that is searchable at a later time in JS (or in normal form submission)
Bug with document.createElement() in IE
http://webbugtrack.blogspot.com/2007/10/bug-235-createelement-is-broken-in-ie.html
Due to bug with [element].setAttribute() in IE
http://webbugtrack.blogspot.com/2007/08/bug-242-setattribute-doesnt-always-work.html
cheers
> Pressing a download button corrupts other button actions in Internet Explorer
> -----------------------------------------------------------------------------
>
> Key: MYFACES-1804
> URL: https://issues.apache.org/jira/browse/MYFACES-1804
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
> Affects Versions: 1.2.0
> Environment: Microsoft internet Explorer 6.0 (not tested for other versions)
> Reporter: Thomas Fischer
> Attachments: myfaces-1804.patch, testHiddenInputJavascript.html, testie.jsp, TestieController.java
>
>
> Situation: The user accesses a jsf page where a commandlink or commandButton starts a download, and other commandLinks or CommandButtons are present in the same form, using the internet explorer as a browser. The user e clicks on the download Button. Afterwards, the user clicks on any other button in the same form.
> Observed behaviour: The previous download is started again, regardless of the action associated with the button
> Expected behaviour: The action associated with the button should be executed
> Analysis: The error originates in the generated javascript function oamSetHiddenInput(formname, name, value). In this function, it is checked whether the hidden input already exists, using the javascript code
> if(typeof form.elements[name]=='undefined')
> This works fine in the Internet explorer as long as the hidden input was created in html. If the hidden input was created using javascript, e.g. by the code in the same function, the above condition returns true although the hidden input already exists. This results in creating a second hidden input field instead of replacing the value in the existing one. If the server only uses the value of the first(i.e. already existing) hidden input field, it gets the old value instead of the new one. In the end, myfaces reads the old value of the html parameter ${formName}:_idcl, and so the old action is executed instead of the new one.
> Resolution: Accessing the hidden input via indices (form.elements[0], form.elements[1] ...) also works if the hidden input is created dynamically.
> Note that the error does only occur if the page is not reloaded when the first button is pressed, so a special action as e.g. a download is needed to trigger the behaviour.
> I'd consider this to be a bug in IE, but as we cannot persuade all users to use a browser which is less buggy, a workaround should be implemented in myfaces. The error does not occur in Firefox.
> As the implementation is in the myfaces_shared project, this affects both core and tomahawk.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.