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