[jira] Commented: (MYFACES-1804) Pressing a download button corrupts other button actions in Internet Explorer

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