July 2014 - richfaces-issues - Jboss List Archives

[JBoss JIRA] (RF-13709) Remove the chart components from the RichFaces mobile showcase

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/RF-13709?page=com.atlassian.jira.plugin.s... ] Matej Novotny closed RF-13709. ------------------------------ Verified, closing issue. > Remove the chart components from the RichFaces mobile showcase > -------------------------------------------------------------- > > Key: RF-13709 > URL: https://issues.jboss.org/browse/RF-13709 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: showcase > Reporter: Brian Leathem > Assignee: Brian Leathem > Priority: Minor > Fix For: 4.5.0.Alpha3 > > Original Estimate: 15 minutes > Remaining Estimate: 15 minutes > > The chart components need additional work to function in a mobile environment. In the mean time we should remove them from the mobile showcase. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RF-13720) Mobile Showcase - CSV demo with JS error and does not work

by Juraj Húska (JIRA)

[ https://issues.jboss.org/browse/RF-13720?page=com.atlassian.jira.plugin.s... ] Juraj Húska updated RF-13720: ----------------------------- Steps to Reproduce: # deploy showcase, and load: http://localhost:8080/showcase/mobile/#clientValidation:jsr303 # ensure that the browser cache was clear before page loading # type one character to input and make a blur over the input # see that there are no error messages > 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

1
0
0 / 0

[JBoss JIRA] (RF-13720) Mobile Showcase - CSV demo with JS error and does not work

by Juraj Húska (JIRA)

[ https://issues.jboss.org/browse/RF-13720?page=com.atlassian.jira.plugin.s... ] Juraj Húska commented on RF-13720: ---------------------------------- Yes, I tried it again, and desktop version works fine. Function {{RichFaces.csv.validate}} is available after a page refresh. > 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

1
0
0 / 0

[JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated

by Pavol Pitonak (JIRA)

[ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.s... ] Pavol Pitonak commented on RF-13706: ------------------------------------ As Michal wrote, everything works fine now. [~marcelkolsteren], FYI you can see results of Jenkins jobs here https://hudson.jboss.org/hudson/view/Richfaces/job/richfaces-4.3-core. I updated Jenkins notifications to contain this link. > 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

1
0
0 / 0

[JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated

by Michal Petrov (JIRA)

[ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.s... ] Michal Petrov commented on RF-13706: ------------------------------------ [~marcelkolsteren] it wasn't your fault :) Jenkins couldn't access the JBoss repo for some reason (there might have been a maintenance), the later builds are passing. > 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

1
0
0 / 0

[JBoss JIRA] (RF-13597) Drag and drop support for file upload

by Jiří Štefek (JIRA)

[ https://issues.jboss.org/browse/RF-13597?page=com.atlassian.jira.plugin.s... ] Jiří Štefek closed RF-13597. ---------------------------- Good job. Looks good on all mentioned browsers. Verified, closing. > Drag and drop support for file upload > ------------------------------------- > > Key: RF-13597 > URL: https://issues.jboss.org/browse/RF-13597 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component > Affects Versions: 4.1.0.Final > Reporter: abhishek vijra > Assignee: Michal Petrov > Fix For: 4.5.0.Alpha3 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > Drag/Drop support should be added to file upload component . > Like the primefaces fileUploadDnd : http://www.primefaces.org/showcase/ui/fileUploadDnd.jsf -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RF-13723) fileUpload: 'Clear All' button does not work after maxFilesQuantity reached on IE

by Jiří Štefek (JIRA)

Jiří Štefek created RF-13723: -------------------------------- Summary: fileUpload: 'Clear All' button does not work after maxFilesQuantity reached on IE Key: RF-13723 URL: https://issues.jboss.org/browse/RF-13723 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-input Affects Versions: 4.5.0.Alpha3 Environment: IE 11, IE 10 Reporter: Jiří Štefek Priority: Minor The 'Clear All' button does nothing when clicked after maxFilesQuantity reached by adding items using the 'Add' button. It works after items were added by DnD. You have to click somewhere on the page, to get the button working. It works fine in FF, Chrome. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RF-12448) Calendar: April 2011 is missing when timezone is set to +2 Asia/Amman (EEST)

by John Kiro (JIRA)

[ https://issues.jboss.org/browse/RF-12448?page=com.atlassian.jira.plugin.s... ] John Kiro commented on RF-12448: -------------------------------- The issue is still there, and reproducible even on the showcase of RF 5 ( version 5.0.0.Alpha3) (http://showcase5-richfaces.rhcloud.com/richfaces/component-sample.jsf?dem...). In my opinion, the fix is not that difficult, and given the priority (still set to Critical for more than 3 years), it should take more attention. Will add more information subsequently about my observation in the component Javascript code. > Calendar: April 2011 is missing when timezone is set to +2 Asia/Amman (EEST) > ---------------------------------------------------------------------------- > > Key: RF-12448 > URL: https://issues.jboss.org/browse/RF-12448 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-input, localization > Environment: RichFaces 4.3.0.M1 > JBoss AS 7.1.1.Final > Google Chrome 21.0.1180.89 > Reporter: Pavol Pitonak > Priority: Critical > Fix For: 5-Tracking > > Attachments: calendar.png > > > # deploy Showcase and open http://localhost:8080/showcase/richfaces/component-sample.jsf?demo=calend... > # click on input to open calendar's popup > # navigate to April 2011 > result: > * there is no April 2011 > * March 2011 is gray and contains only 1s (see screenshot) -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RF-13722) Document CDK Maven Changes for 4.5

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13722?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13722: ------------------------------- Fix Version/s: 4.5.0.Beta1 (was: 4.5-Tracking) > 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.0.Beta1 > > > 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

1
0
0 / 0

[JBoss JIRA] (RF-13722) Document CDK Maven Changes for 4.5

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13722?page=com.atlassian.jira.plugin.s... ] Brian Leathem commented on RF-13722: ------------------------------------ Great, thanks for filing this [~clerum]. Agreed, the rest ofthe CDK docs are in the wiki atm, so a wiki page addresseing CDK 4.3 to 4.5 migrations would be the best place to hang this for now. > 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.0.Beta1 > > > 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

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

richfaces-issues July 2014