[JBoss JIRA] (RF-13701) RF 4.5 Bar chart plotClick malfunctioning
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/RF-13701?page=com.atlassian.jira.plugin.s... ]
Matej Novotny closed RF-13701.
------------------------------
Verified, clicking any plot now fires an event.
Closing issue.
> RF 4.5 Bar chart plotClick malfunctioning
> -----------------------------------------
>
> Key: RF-13701
> URL: https://issues.jboss.org/browse/RF-13701
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-output
> Affects Versions: 4.5.0.Alpha3
> Environment: Wildfly 8.0
> Latest Chrome/FF
> Reporter: Matej Novotny
> Assignee: Brian Leathem
> Fix For: 4.5.0.Alpha3
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> When interacting with bar chart where {{onplotclick}} and {{plotClickListener}} are set, it does not react when last bar in the series is clicked (eg .no request is sent for server side event and no JS executed for onplotclick). See steps to reproduce, in case they are not clear ask me for more details.
> I created Metamer samples of charts for 4.5.x where this can be tested (only manually for the time being).
> This works in RF 5, so this has to be connected to backporting charts component (RF-13583) to 4.5.x.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 12 months
[JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.s... ]
Brian Leathem resolved RF-13706.
--------------------------------
Resolution: Done
> 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)
9 years, 12 months
[JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.s... ]
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)
9 years, 12 months
[JBoss JIRA] (RF-13682) Stateless view: CSS stylesheets not included in head after form submit
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13682?page=com.atlassian.jira.plugin.s... ]
Brian Leathem resolved RF-13682.
--------------------------------
Labels: needs-qe (was: )
Resolution: Done
Changed the GlobalResourcesViewHandler to add the skinning resources during the restoreView, instead of only during the createView.
> Stateless view: CSS stylesheets not included in head after form submit
> ----------------------------------------------------------------------
>
> Key: RF-13682
> URL: https://issues.jboss.org/browse/RF-13682
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.7
> Environment: OpenSuse 13.1 x64
> OpenJDK 1.7.0_51
> Apache Tomcat 8.0.8
> JSF: org.glassfish:javax.faces:2.1.28
> Reporter: Tony Cramer
> Assignee: Brian Leathem
> Labels: needs-qe
> Fix For: 4.5.0.Alpha3
>
> Attachments: rf-demo-skinning.zip, rf-demo-skinning_and_style.zip
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> If view is stateless <f:view transient="true"...
> Issue 1. skinning.css is not included after submitting a form at all.
> Issue 2. Any other stylesheets manually included with h:outputStylesheet are not included in head but in body after submit.
> Maven project reproducing the issue attached.
> Please use "rf-demo-skinning_and_style.zip" - reproduces both issues.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 12 months
[JBoss JIRA] (RF-13682) Stateless view: CSS stylesheets not included in head after form submit
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13682?page=com.atlassian.jira.plugin.s... ]
Brian Leathem edited comment on RF-13682 at 7/8/14 8:37 PM:
------------------------------------------------------------
Disregard the comment below, I was confused. I have since found a resolution to the issue. I will delete this comment since it adds nothing of value to the conversation.
----
On further investigation, it seems that the _RestoreViewPhase#execute_ method believes the submission is a _postback_. The view is then not created anew, despite the subsequemt response consisting of the full page html.
Whether or not the submission is a _postback_ is determined by the _[ResponseStateManagerImpl|https://github.com/jboss/mojarra/blob/2.2.7-jb...:
{code}
public boolean isPostback(FacesContext context) {
return context.getExternalContext().getRequestParameterMap().
containsKey(ResponseStateManager.VIEW_STATE_PARAM);
}
{code}
The _requestParameterMap_ contains the {{VIEW_STATE_PARAM}} value _stateless_. It seems this was added in RF-13093.
[~lfryc] can you comment on the addition of this request parameter? Since it's causing difficulties elsewhere, can you suggest an alternate resolution for RF-13093?
was (Author: bleathem):
On further investigation, it seems that the _RestoreViewPhase#execute_ method believes the submission is a _postback_. The view is then not created anew, despite the subsequemt response consisting of the full page html.
Whether or not the submission is a _postback_ is determined by the _[ResponseStateManagerImpl|https://github.com/jboss/mojarra/blob/2.2.7-jb...:
{code}
public boolean isPostback(FacesContext context) {
return context.getExternalContext().getRequestParameterMap().
containsKey(ResponseStateManager.VIEW_STATE_PARAM);
}
{code}
The _requestParameterMap_ contains the {{VIEW_STATE_PARAM}} value _stateless_. It seems this was added in RF-13093.
[~lfryc] can you comment on the addition of this request parameter? Since it's causing difficulties elsewhere, can you suggest an alternate resolution for RF-13093?
> Stateless view: CSS stylesheets not included in head after form submit
> ----------------------------------------------------------------------
>
> Key: RF-13682
> URL: https://issues.jboss.org/browse/RF-13682
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.7
> Environment: OpenSuse 13.1 x64
> OpenJDK 1.7.0_51
> Apache Tomcat 8.0.8
> JSF: org.glassfish:javax.faces:2.1.28
> Reporter: Tony Cramer
> Assignee: Brian Leathem
> Fix For: 4.5.0.Alpha3
>
> Attachments: rf-demo-skinning.zip, rf-demo-skinning_and_style.zip
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> If view is stateless <f:view transient="true"...
> Issue 1. skinning.css is not included after submitting a form at all.
> Issue 2. Any other stylesheets manually included with h:outputStylesheet are not included in head but in body after submit.
> Maven project reproducing the issue attached.
> Please use "rf-demo-skinning_and_style.zip" - reproduces both issues.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 12 months
[JBoss JIRA] (RF-13682) Stateless view: CSS stylesheets not included in head after form submit
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13682?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13682:
-------------------------------
Comment: was deleted
(was: Disregard the comment below, I was confused. I have since found a resolution to the issue. I will delete this comment since it adds nothing of value to the conversation.
----
On further investigation, it seems that the _RestoreViewPhase#execute_ method believes the submission is a _postback_. The view is then not created anew, despite the subsequemt response consisting of the full page html.
Whether or not the submission is a _postback_ is determined by the _[ResponseStateManagerImpl|https://github.com/jboss/mojarra/blob/2.2.7-jb...:
{code}
public boolean isPostback(FacesContext context) {
return context.getExternalContext().getRequestParameterMap().
containsKey(ResponseStateManager.VIEW_STATE_PARAM);
}
{code}
The _requestParameterMap_ contains the {{VIEW_STATE_PARAM}} value _stateless_. It seems this was added in RF-13093.
[~lfryc] can you comment on the addition of this request parameter? Since it's causing difficulties elsewhere, can you suggest an alternate resolution for RF-13093?)
> Stateless view: CSS stylesheets not included in head after form submit
> ----------------------------------------------------------------------
>
> Key: RF-13682
> URL: https://issues.jboss.org/browse/RF-13682
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.7
> Environment: OpenSuse 13.1 x64
> OpenJDK 1.7.0_51
> Apache Tomcat 8.0.8
> JSF: org.glassfish:javax.faces:2.1.28
> Reporter: Tony Cramer
> Assignee: Brian Leathem
> Fix For: 4.5.0.Alpha3
>
> Attachments: rf-demo-skinning.zip, rf-demo-skinning_and_style.zip
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> If view is stateless <f:view transient="true"...
> Issue 1. skinning.css is not included after submitting a form at all.
> Issue 2. Any other stylesheets manually included with h:outputStylesheet are not included in head but in body after submit.
> Maven project reproducing the issue attached.
> Please use "rf-demo-skinning_and_style.zip" - reproduces both issues.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 12 months
[JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated
by Marcel Kolsteren (JIRA)
[ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.s... ]
Marcel Kolsteren commented on RF-13706:
---------------------------------------
I just signed a JBoss CLA for contributing to RichFaces.
> 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)
9 years, 12 months
[JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated
by Marcel Kolsteren (JIRA)
[ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.s... ]
Marcel Kolsteren commented on RF-13706:
---------------------------------------
I remember vaguely that by the time I was developing the fix, I saw this unit test failing, but it failed only once.
I just cloned the latest version of the core module, with my fix inside, and I ran "mvn install" 5 times, without any unit test failing. When looking at the test (QUnitTest#testQueueRequest), I see that it is checking the timing of Ajax requests. Timing related test tend to have a bigger chance of being unstable themselves.
So my question is: is the failure of this unit test reproducible?
> 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)
9 years, 12 months
[JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated
by Marcel Kolsteren (JIRA)
[ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.s... ]
Marcel Kolsteren edited comment on RF-13706 at 7/8/14 3:37 PM:
---------------------------------------------------------------
I remember vaguely that by the time I was developing the fix, I saw this unit test failing, but it failed only once.
I just cloned the latest version of the core module, with my fix inside, and I ran "mvn install" 5 times, without any unit test failing. When looking at the test (QUnitTest#testQueueRequest), I see that it is checking the timing of Ajax requests. Timing related tests tend to have a bigger chance of being unstable themselves.
So my question is: is the failure of this unit test reproducible?
was (Author: marcelkolsteren):
I remember vaguely that by the time I was developing the fix, I saw this unit test failing, but it failed only once.
I just cloned the latest version of the core module, with my fix inside, and I ran "mvn install" 5 times, without any unit test failing. When looking at the test (QUnitTest#testQueueRequest), I see that it is checking the timing of Ajax requests. Timing related test tend to have a bigger chance of being unstable themselves.
So my question is: is the failure of this unit test reproducible?
> 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)
9 years, 12 months
[JBoss JIRA] (RF-13678) Render @all does not work for nested a4j:region in collapsibleSubTable
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/RF-13678?page=com.atlassian.jira.plugin.s... ]
Michal Petrov resolved RF-13678.
--------------------------------
Resolution: Duplicate Issue
Resolving as duplicate, pull request from RF-11093 did fix the issue.
> Render @all does not work for nested a4j:region in collapsibleSubTable
> ----------------------------------------------------------------------
>
> Key: RF-13678
> URL: https://issues.jboss.org/browse/RF-13678
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.5.0.Alpha3
> Reporter: Juraj Húska
> Assignee: Michal Petrov
> Labels: regression
> Fix For: 4.5.0.Alpha3
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> Suppose nested {{regions}} in a {{collapsibleSubTable}}.
> Those regions are not updated when a {{commandButton}} with {{render}} attribute set to {{@all}} is submitted.
> IMHO it is somehow connected with RF-13677, however, this issue occurs only with combination of {{regions}} and {{collapsibleSubTable}}, other iteration components works in this matter.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 12 months