From issues at jboss.org Mon Jun 30 04:03:24 2014 Content-Type: multipart/mixed; boundary="===============5661233837799836542==" MIME-Version: 1.0 From: Marcel Kolsteren (JIRA) To: richfaces-issues at lists.jboss.org Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated Date: Mon, 30 Jun 2014 04:03:24 -0400 Message-ID: In-Reply-To: JIRA.12545079.1404115318552@jira02.app.mwc.hst.phx2.redhat.com --===============5661233837799836542== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Marcel Kolsteren created RF-13706: ------------------------------------- Summary: 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: component-a4j-core Affects Versions: 4.3.7 Reporter: Marcel Kolsteren 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 inclu= des the source element of the next request in the queue, but does not inclu= de the form of that source element. When the next request is fetched from t= he queue, JSF tries to find the correct form by climbing the DOM tree, star= ting at the source element of the event. However, because the source elemen= t 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 happ= en. 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}
{noformat} The method "waitThreeSeconds" does nothing but waiting for three seconds. W= hen the link is double clicked, you'll observe that the first click is hand= led 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 c= ross 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 q= ueue. I created a patch for RichFaces 4.3.7, and verified that it works (se= e attachment). Another solution strategy would be to try to find the new DO= M 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 woul= d be better, because (1) it is kind of dangerous to process a user action o= n 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) --===============5661233837799836542==--