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