[
https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Leathem updated RF-13706:
-------------------------------
Original Estimate: 1 hour
Remaining Estimate: 1 hour
Sprint: 4.5.0.Alpha3 - Sprint 5
> dequeued Ajax request not processed correctly if its source element has been
> updated
> ------------------------------------------------------------------------------------
>
> Key: RF-13706
> URL: https://issues.jboss.org/browse/RF-13706
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.3.7
> Reporter: Marcel Kolsteren
> Assignee: Marcel Kolsteren
> Fix For: 4.3.8, 4.5.0.Alpha3
>
> Attachments: queuetest-javaee6.zip, queuetest.zip,
> richfaces-core-4.3.8-SNAPSHOT.patch.zip
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> I found a problem in the RichFaces Ajax queuing mechanism, which can cause
> all JavaScript execution to stop, leaving the end user with an unresponsive
> page.
> The problem occurs when a request in the queue rerenders an area that
> includes the source element of the next request in the queue, but does not
> include the form of that source element. When the next request is fetched
> from the queue, JSF tries to find the correct form by climbing the DOM tree,
> starting at the source element of the event. However, because the source
> element has been rerendered, the path to its form is broken, and in that case
> JSF falls back to the first form of the page (see JavaScript function getForm
> that is called by jsf.ajax.request in jsf.js). If that form is not the form
> belonging to the rerendered version of the element, nasty things will happen.
> To illustrate this, I created a very simple Java EE 7 web application (see
> attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a
> page with one clickable link that rerenders itself when clicked:
> {noformat}
> <!DOCTYPE html>
> <html xmlns="http://www.w3.org/1999/xhtml";
> xmlns:h="http://java.sun.com/jsf/html";
> xmlns:a4j="http://richfaces.org/a4j";>
> <h:head/>
> <h:body>
> <form action="http://www.meandi.nl"/>
> <h:form>
> <a4j:commandLink action="#{richBean.waitThreeSeconds}" value="Click
> Me" render="@this"/>
> </h:form>
> </h:body>
> </html>
> {noformat}
> The method "waitThreeSeconds" does nothing but waiting for three seconds.
> When the link is double clicked, you'll observe that the first click is
> handled correctly, but that the second click results in an Ajax request
> posted to the URL of the first form, leading to access denied errors (because
> of cross domain scripting). The used RichFaces version is 4.3.7.
> The problem can be fixed by changing the RichFaces JavaScript code, so that
> after completion of an Ajax request, stale elements are removed from the
> queue. I created a patch for RichFaces 4.3.7, and verified that it works (see
> attachment). Another solution strategy would be to try to find the new DOM
> element that corresponds to the stale source of the event, and fetch the form
> from that element. My thought was that removing the stale request would be
> better, because (1) it is kind of dangerous to process a user action on an
> element that has already been replaced and (2) the element might have been
> removed from the DOM tree by the previous rerender.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
_______________________________________________
richfaces-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/richfaces-issues
