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