From issues at jboss.org Tue Jul 1 16:14:24 2014 Content-Type: multipart/mixed; boundary="===============6219624228431247396==" 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: Tue, 01 Jul 2014 16:14:24 -0400 Message-ID: In-Reply-To: JIRA.12545079.1404115318000@jira02.app.mwc.hst.phx2.redhat.com --===============6219624228431247396== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable [ https://issues.jboss.org/browse/RF-13706?page=3Dcom.atlassian.jira.pl= ugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D12981190#com= ment-12981190 ] = Marcel Kolsteren commented on RF-13706: --------------------------------------- Thanks! I changed the RichFaces dependency to the 4.5 snapshot artifact sup= plied by Pavol, and deployed my sample application in WildFly 8.1.0.Final. = The problem was still there (as expected). It would be great if you included the fix for this issue in the upcoming 4.= 3.8 release as well. > dequeued Ajax request not processed correctly if its source element has b= een 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: Juraj H=C3=BAska > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core= -4.3.8-SNAPSHOT.patch.zip > > > I found a problem in the RichFaces Ajax queuing mechanism, which can caus= e all JavaScript execution to stop, leaving the end user with an unresponsi= ve page. > The problem occurs when a request in the queue rerenders an area that inc= ludes the source element of the next request in the queue, but does not inc= lude 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, st= arting at the source element of the event. However, because the source elem= ent has been rerendered, the path to its form is broken, and in that case J= SF falls back to the first form of the page (see JavaScript function getFor= m that is called by jsf.ajax.request in jsf.js). If that form is not the fo= rm belonging to the rerendered version of the element, nasty things will ha= ppen. > To illustrate this, I created a very simple Java EE 7 web application (se= e attached Maven project) and deployed it in WildFly 8.1.0.Final. It contai= ns a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h=3D"http://java.sun.com/jsf/html" > xmlns:a4j=3D"http://richfaces.org/a4j"> > > >
> > > > > > {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 ha= ndled correctly, but that the second click results in an Ajax request poste= d 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 th= at 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 th= e form from that element. My thought was that removing the stale request wo= uld 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 hav= e been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) --===============6219624228431247396==--