[JBoss JIRA] (RF-13722) Document CDK Maven Changes for 4.5
by Cody Lerum (JIRA)
Cody Lerum created RF-13722:
-------------------------------
Summary: Document CDK Maven Changes for 4.5
Key: RF-13722
URL: https://issues.jboss.org/browse/RF-13722
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: cdk
Affects Versions: 4.5.0.Alpha3
Reporter: Cody Lerum
Fix For: 4.5-Tracking
The maven build requires a 2 step process now with a set to precompile before the cdk runs
{code}
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<executions>
<execution>
<id>precompile-sources-for-cdk</id>
<phase>generate-sources</phase>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.richfaces.cdk</groupId>
<artifactId>richfaces-cdk-maven-plugin</artifactId>
<version>${org.richfaces.cdk.version}</version>
<executions>
<execution>
<id>cdk-generate-sources</id>
<phase>process-sources</phase>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
{code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (RF-13722) Document CDK Maven Changes for 4.5
by Cody Lerum (JIRA)
[ https://issues.jboss.org/browse/RF-13722?page=com.atlassian.jira.plugin.s... ]
Cody Lerum commented on RF-13722:
---------------------------------
Document in wiki
> Document CDK Maven Changes for 4.5
> ----------------------------------
>
> Key: RF-13722
> URL: https://issues.jboss.org/browse/RF-13722
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: cdk
> Affects Versions: 4.5.0.Alpha3
> Reporter: Cody Lerum
> Fix For: 4.5-Tracking
>
>
> The maven build requires a 2 step process now with a set to precompile before the cdk runs
> {code}
> <plugins>
> <plugin>
> <artifactId>maven-compiler-plugin</artifactId>
> <executions>
> <execution>
> <id>precompile-sources-for-cdk</id>
> <phase>generate-sources</phase>
> <goals>
> <goal>compile</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
> <plugin>
> <groupId>org.richfaces.cdk</groupId>
> <artifactId>richfaces-cdk-maven-plugin</artifactId>
> <version>${org.richfaces.cdk.version}</version>
> <executions>
> <execution>
> <id>cdk-generate-sources</id>
> <phase>process-sources</phase>
> <goals>
> <goal>generate</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
> </plugins>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 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 received a mail from "ci-builds" at RedHat that the build "richfaces-4.3-core - Build # 347" failed. But I don't have access to the Jenkins page that shows the details, and on my local machine a "mvn install" on the RichFaces core module runs fine. What went wrong in that build and is it related to my PR?
> 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)
10 years, 4 months
[JBoss JIRA] (RF-13720) Mobile Showcase - CSV demo with JS error and does not work
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13720?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13720:
-------------------------------
Priority: Major (was: Critical)
> Mobile Showcase - CSV demo with JS error and does not work
> ----------------------------------------------------------
>
> Key: RF-13720
> URL: https://issues.jboss.org/browse/RF-13720
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.5.0.Alpha3
> Environment: mobile devices
> Reporter: Juraj Húska
> Labels: mobile, regression
>
> Showcase demo for _client side validation_ is not working on mobile devices.
> There is a JS error thrown, stating:
> {code}
> TypeError: RichFaces.csv.validate is not a function
> if(clientHandler){clientHandler.call(this,event)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (RF-13720) Mobile Showcase - CSV demo with JS error and does not work
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13720?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13720:
-------------------------------
Fix Version/s: 4.5.0.Beta1
> Mobile Showcase - CSV demo with JS error and does not work
> ----------------------------------------------------------
>
> Key: RF-13720
> URL: https://issues.jboss.org/browse/RF-13720
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.5.0.Alpha3
> Environment: mobile devices
> Reporter: Juraj Húska
> Labels: mobile, regression
> Fix For: 4.5.0.Beta1
>
>
> Showcase demo for _client side validation_ is not working on mobile devices.
> There is a JS error thrown, stating:
> {code}
> TypeError: RichFaces.csv.validate is not a function
> if(clientHandler){clientHandler.call(this,event)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal
by Ken Finnigan (JIRA)
[ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.s... ]
Ken Finnigan commented on RF-13719:
-----------------------------------
I know that's something that is tested, and last time I did it worked fine.
One comment would be that the reproducer is using RF 4.3.1.Final, not 4.3.5.Final, and it also uses PBR 3.2.0.Final, which I'm pretty sure is the incorrect version for JPP 6.1.1
[~jtrantin], have you spoken with JPP QE about this? Maybe [~pmensik] can assist?
> rich.fileUpload breaks form action in portal
> --------------------------------------------
>
> Key: RF-13719
> URL: https://issues.jboss.org/browse/RF-13719
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.3.5
> Environment: JBoss Portal 6.1.1
> Reporter: Jonáš Trantina
> Labels: gss
> Attachments: reproducer.zip
>
>
> When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well.
> In fileupload.js __submit method there is the following code:
> {code:JavaScript}
> var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']");
> var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action");
> {code}
> the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails.
> In portal the solution is
> {code:JavaScript}
> var originalFormAction =this.form.attr("action");
> {code}
> and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments.
> Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly?
> To reproduce you can use the reproducer attached.
> Example URLs:
> form action
> {code}
> /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action
> {code}
> input[name='javax.faces.encodedURL']
> {code}
> /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (RF-13721) dataTable: columnClasses attribute doesn't work as described
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13721?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13721:
-------------------------------
Fix Version/s: 4.5-Tracking
> dataTable: columnClasses attribute doesn't work as described
> ------------------------------------------------------------
>
> Key: RF-13721
> URL: https://issues.jboss.org/browse/RF-13721
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.3.7, 4.5.0.Alpha2, 5.0.0.Alpha3
> Reporter: Michal Petrov
> Fix For: 4.5-Tracking
>
>
> The description of @columnClasses says
> bq. … If you have less class names than columns, the class will be applied to every n-fold column where n is the order in which the class is listed in the attribute.
> This is not the case, if you define n classes they will only be applied to the first n columns. This only affects components that use AbstractRowRenderer.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (RF-13720) Mobile Showcase - CSV demo with JS error and does not work
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13720?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13720:
------------------------------------
Are we sure this works on Desktop? The same resources should be served in both cases, so it surprises me that this erros on mobile but not desktop.
> Mobile Showcase - CSV demo with JS error and does not work
> ----------------------------------------------------------
>
> Key: RF-13720
> URL: https://issues.jboss.org/browse/RF-13720
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.5.0.Alpha3
> Environment: mobile devices
> Reporter: Juraj Húska
> Priority: Critical
> Labels: mobile, regression
>
> Showcase demo for _client side validation_ is not working on mobile devices.
> There is a JS error thrown, stating:
> {code}
> TypeError: RichFaces.csv.validate is not a function
> if(clientHandler){clientHandler.call(this,event)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13719:
-------------------------------
Labels: gss (was: )
> rich.fileUpload breaks form action in portal
> --------------------------------------------
>
> Key: RF-13719
> URL: https://issues.jboss.org/browse/RF-13719
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.3.5
> Environment: JBoss Portal 6.1.1
> Reporter: Jonáš Trantina
> Labels: gss
> Attachments: reproducer.zip
>
>
> When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well.
> In fileupload.js __submit method there is the following code:
> {code:JavaScript}
> var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']");
> var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action");
> {code}
> the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails.
> In portal the solution is
> {code:JavaScript}
> var originalFormAction =this.form.attr("action");
> {code}
> and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments.
> Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly?
> To reproduce you can use the reproducer attached.
> Example URLs:
> form action
> {code}
> /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action
> {code}
> input[name='javax.faces.encodedURL']
> {code}
> /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13719:
------------------------------------
[~kenfinni]: any insight here?
> rich.fileUpload breaks form action in portal
> --------------------------------------------
>
> Key: RF-13719
> URL: https://issues.jboss.org/browse/RF-13719
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.3.5
> Environment: JBoss Portal 6.1.1
> Reporter: Jonáš Trantina
> Labels: gss
> Attachments: reproducer.zip
>
>
> When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well.
> In fileupload.js __submit method there is the following code:
> {code:JavaScript}
> var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']");
> var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action");
> {code}
> the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails.
> In portal the solution is
> {code:JavaScript}
> var originalFormAction =this.form.attr("action");
> {code}
> and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments.
> Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly?
> To reproduce you can use the reproducer attached.
> Example URLs:
> form action
> {code}
> /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action
> {code}
> input[name='javax.faces.encodedURL']
> {code}
> /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months