[
https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983326#comment-12983326
]
Brian Leathem commented on RF-13706:
------------------------------------
Thanks [~marcelkolsteren] for signing the CLA.
The unit tests fail pretty consistently on my machine. The tests are indeed
timing related. It occurs to me that by removing entries from the top of the
queue we are messing with the _requestDelay_ that a user might set. I am able
to avoid this problem (and get the unit tests to pass) if I change the attached
patch to:
{code}
var removeStaleEntriesFromQueue = function () {
var entry;
var foundValidEntry = false;
while (items.length > 0 && !foundValidEntry) {
entry = items[0];
if (entry.getReadyToSubmit() === true) {
var element = richfaces.getDomElement(entry.source);
if (element == null || $(element).closest("form").length ==
0) {
items.shift();
richfaces.log.debug("richfaces.queue: removing stale
entry from the queue (source element: " + element + ")");
} else {
foundValidEntry = true;
}
} else {
foundValidEntry = true;
}
}
}
{code}
Note: the check to see if the entry is readyToSubmit prior to removing the
entry.
[~ppitonak]: this is precisely why I asked QE to verify this PR was stable
prior to merging the PR. Unit tests should be part of our QA verification
process. (Ideally we would have a CI tool that verified PRs, like travis-ci)
> 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
