From issues at jboss.org Mon Jul 7 17:30:24 2014 Content-Type: multipart/mixed; boundary="===============9160760753379047744==" MIME-Version: 1.0 From: Brian Leathem (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, 07 Jul 2014 17:30:24 -0400 Message-ID: In-Reply-To: JIRA.12545079.1404115318000@jira02.app.mwc.hst.phx2.redhat.com --===============9160760753379047744== 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=3D12982812#com= ment-12982812 ] = Brian Leathem commented on RF-13706: ------------------------------------ [~marcelkolsteren] I forgot to ask, can you sign the JBoss CLA? https://cla.jboss.org/index.seam Thanks! > 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: 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 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) --===============9160760753379047744==--