July 2014 - richfaces-issues - Jboss List Archives

[JBoss JIRA] (RF-13675) Showcase: chart component improvements

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13675?page=com.atlassian.jira.plugin.s... ] Brian Leathem resolved RF-13675. -------------------------------- Resolution: Done > Showcase: chart component improvements > -------------------------------------- > > Key: RF-13675 > URL: https://issues.jboss.org/browse/RF-13675 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Lukáš Macko > Assignee: Brian Leathem > Priority: Minor > Fix For: 4.5.0.Alpha3 > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > The chart sample on the showcase needs some descriptive text. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (RF-13675) Showcase: chart component improvements

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13675?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13675: ------------------------------- Description: The chart sample on the showcase needs some descriptive text. > Showcase: chart component improvements > -------------------------------------- > > Key: RF-13675 > URL: https://issues.jboss.org/browse/RF-13675 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Lukáš Macko > Assignee: Brian Leathem > Priority: Minor > Fix For: 4.5.0.Alpha3 > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > The chart sample on the showcase needs some descriptive text. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (RF-13701) RF 4.5 Bar chart plotClick malfunctioning

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13701?page=com.atlassian.jira.plugin.s... ] Brian Leathem resolved RF-13701. -------------------------------- Resolution: Done Replaced the xaxis.ticks lookup to use the dataIndex instead of the seriesIndex > 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

1
0
0 / 0

[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 updated RF-13706: ------------------------------- Fix Version/s: 4.3.8 > 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: Brian Leathem > Fix For: 4.3.8, 4.5.0.Alpha3 > > 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 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

1
0
0 / 0

[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 updated RF-13706: ------------------------------- Fix Version/s: 4.5.0.Alpha3 > 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: Brian Leathem > Fix For: 4.5.0.Alpha3 > > 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 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

1
0
0 / 0

[JBoss JIRA] (RF-13713) Create Smoke test(s) for chart in RF 4.5

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13713?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13713: ------------------------------- Affects Version/s: 4.5.0.Alpha3 (was: 4.5.0.Alpha2) > Create Smoke test(s) for chart in RF 4.5 > ---------------------------------------- > > Key: RF-13713 > URL: https://issues.jboss.org/browse/RF-13713 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Reporter: Matej Novotny > Assignee: Matej Novotny > Priority: Minor > Fix For: 4.5.0.Alpha2 > > > As charts were added recently we have no tests covering this component. > We need to have at least some smoke test too quickly determine when something goes wrong. Rest can be tested in Metamer. > These tests might run only with some browsers - investigate. > Also test JS API because it will be needed in order to test listeners. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (RF-13714) DropDownMenu not working inside tab-header

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13714?page=com.atlassian.jira.plugin.s... ] Brian Leathem reassigned RF-13714: ---------------------------------- Assignee: Pavol Pitonak QE please verify > DropDownMenu not working inside tab-header > ------------------------------------------ > > Key: RF-13714 > URL: https://issues.jboss.org/browse/RF-13714 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-menu > Affects Versions: 4.3.7 > Environment: Wildfly 8.1.0.GA => JSF 2.2 > Tested with recent Firefox and Chromium versions. > Reporter: Martin Höller > Assignee: Pavol Pitonak > Labels: dropDownMenu, tabPanel > > The <rich:dropDownMenu> component seems broken, when used in the header-fact of a <rich:tab>. The menu simply doesn't open. Here is simplified example-code to reproduce: > {code:xml} > <rich:tabPanel switchType="client"> > <rich:tab> > <f:facet name="header"> > <rich:dropDownMenu showEvent="mouseover" label="menu" mode="client"> > <rich:menuItem> > <a4j:commandLink value="menuItem" /> > </rich:menuItem> > </rich:dropDownMenu> > </f:facet> > </rich:tab> > </rich:tabPanel> > {code} > If I use the same menu-code in the <rich:tab> but outside the header-facet, it works. > This did work with Richfaces 3.3! -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (RF-13713) Create Smoke test(s) for chart in RF 4.5

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13713?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13713: ------------------------------- Fix Version/s: 4.5.0.Alpha3 (was: 4.5.0.Alpha2) > Create Smoke test(s) for chart in RF 4.5 > ---------------------------------------- > > Key: RF-13713 > URL: https://issues.jboss.org/browse/RF-13713 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Reporter: Matej Novotny > Assignee: Matej Novotny > Priority: Minor > Fix For: 4.5.0.Alpha3 > > > As charts were added recently we have no tests covering this component. > We need to have at least some smoke test too quickly determine when something goes wrong. Rest can be tested in Metamer. > These tests might run only with some browsers - investigate. > Also test JS API because it will be needed in order to test listeners. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.s... ] Brian Leathem reopened RF-13712: -------------------------------- > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Labels: waiting_on_user > Attachments: AS error log.png, can't Render.png, chrome js error log.png, file upload done !.png, fileupload error on wildfly.png, Render code.png, Web application libraries and main page structure.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.s... ] Brian Leathem commented on RF-13712: ------------------------------------ >From your stacktraces and facelet files, it seems as though you are using a mix of RichFaces, PrimeFaces, and OmniFaces. Please check whether you can reproduce this issue with RichFaes alone. This will tell us whether we have a problem with our Fileupload component, or whether there is an interop problem with the other libraries. > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Labels: waiting_on_user > Attachments: AS error log.png, can't Render.png, chrome js error log.png, file upload done !.png, fileupload error on wildfly.png, Render code.png, Web application libraries and main page structure.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 12 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