July 2014 - richfaces-issues - Jboss List Archives

[JBoss JIRA] (RF-13690) DataTable in uiRepeat - scrolling in table makes columns unsorted again

by Martin Tomasek (JIRA)

[ https://issues.jboss.org/browse/RF-13690?page=com.atlassian.jira.plugin.s... ] Martin Tomasek edited comment on RF-13690 at 7/14/14 10:05 AM: --------------------------------------------------------------- We can still reproduce issue but only on Wildfly 8.1. with JSF 2.2. Component works fine on EAP 6.3. with JSF < 2.2. We also tried functionality on a5ee6651647f2f07ca89aca6946d3f7b79d967ea and behaviour was the same as I described before. Works on EAP 6.3. didn't work on Wildfly 8.1. was (Author: mtomasek): We can still reproduce issue. Steps to reproduce are exactly the same as before. We also tried functionality on commit a5ee6651647f2f07ca89aca6946d3f7b79d967ea and we were able to reproduce the issue. > DataTable in uiRepeat - scrolling in table makes columns unsorted again > ----------------------------------------------------------------------- > > Key: RF-13690 > URL: https://issues.jboss.org/browse/RF-13690 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj Húska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{DataTable}} is nested in {{uiRepeat}}, then scrolling over the table with {{dataScroller}} makes sorting according to some column broken - the columns are unsorted. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (RF-13690) DataTable in uiRepeat - scrolling in table makes columns unsorted again

by Martin Tomasek (JIRA)

[ https://issues.jboss.org/browse/RF-13690?page=com.atlassian.jira.plugin.s... ] Martin Tomasek reopened RF-13690: --------------------------------- We can still reproduce issue. Steps to reproduce are exactly the same as before. We also tried functionality on commit a5ee6651647f2f07ca89aca6946d3f7b79d967ea and we were able to reproduce the issue. > DataTable in uiRepeat - scrolling in table makes columns unsorted again > ----------------------------------------------------------------------- > > Key: RF-13690 > URL: https://issues.jboss.org/browse/RF-13690 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj Húska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{DataTable}} is nested in {{uiRepeat}}, then scrolling over the table with {{dataScroller}} makes sorting according to some column broken - the columns are unsorted. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (RF-13691) EDT in uiRepeat - selection corrupted in multiple paged table

by Martin Tomasek (JIRA)

[ https://issues.jboss.org/browse/RF-13691?page=com.atlassian.jira.plugin.s... ] Martin Tomasek reopened RF-13691: --------------------------------- We can still reproduce issue. Steps to reproduce are exactly the same as before. We also tried functionality on commit a5ee6651647f2f07ca89aca6946d3f7b79d967ea and we were able to reproduce the issue. > EDT in uiRepeat - selection corrupted in multiple paged table > ------------------------------------------------------------- > > Key: RF-13691 > URL: https://issues.jboss.org/browse/RF-13691 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj Húska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{EDT}} is in {{uiRepeat}} and has multiple pages, then selection of rows functionality does not work as expected. > It seems that there is a problem with row indices. Please see steps to reproduce. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[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: ----------------------------------- [~jtrantin], this seemed somewhat familiar when looking at it today, and I discovered RF-12273. RF-12273 actually introduced the code you refer to in fileUpload.js above, and it was introduced to make the component work in a portlet environment. Without that change, it's not possible to upload files in a portlet at all. There may be a bug somewhere, but as fileUpload is usually used in an Ajax form, without a non Ajax submit, I don't think it's something that has been tested. Not sure if any of that is much help or not > 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, reproducer2.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)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (RF-13694) Update README files for RichFaces 4.5.x

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/RF-13694?page=com.atlassian.jira.plugin.s... ] Matej Novotny closed RF-13694. ------------------------------ Verified, closing issue. > Update README files for RichFaces 4.5.x > --------------------------------------- > > Key: RF-13694 > URL: https://issues.jboss.org/browse/RF-13694 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: doc > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj Húska > Assignee: Brian Leathem > Priority: Minor > Fix For: 4.5.0.Alpha3 > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > {{README.md}} and {{dist/src/main/resources/txt/readme.txt}} need to be updated with RichFaces 4.5.x. > For {{README.md}} e.g.: > * change of the title to RichFaces 4.5 > * remove "New approach to styling based on LESS" > * alter "Smooth Migration from RF4 to RF5" > and other -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

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

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.s... ] Matej Novotny closed RF-13706. ------------------------------ Verified. Works for 4.3.x. As for 4.5.x, this is *not included in 4.5.0.Alpha3*, but the fix works fine for me, so we can include it in the next release. > 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)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (RF-13653) Update component namespaces in 4.5 examples

by Martin Tomasek (JIRA)

[ https://issues.jboss.org/browse/RF-13653?page=com.atlassian.jira.plugin.s... ] Martin Tomasek closed RF-13653. ------------------------------- > Update component namespaces in 4.5 examples > ------------------------------------------- > > Key: RF-13653 > URL: https://issues.jboss.org/browse/RF-13653 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 4.5.0.Alpha3 > Reporter: Michal Petrov > Assignee: Michal Petrov > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > With the exception of showcase, all examples use the r namespace, it needs to be changed back to a4j/rich. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (RF-13651) Integration tests failing in chrome

by Martin Tomasek (JIRA)

[ https://issues.jboss.org/browse/RF-13651?page=com.atlassian.jira.plugin.s... ] Martin Tomasek closed RF-13651. ------------------------------- Verified. > Integration tests failing in chrome > ----------------------------------- > > Key: RF-13651 > URL: https://issues.jboss.org/browse/RF-13651 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: tests - functional > Reporter: Brian Leathem > Assignee: Matej Novotny > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > The framework tests pass in phantomjs but some fail in chrome. > Resolution of this issue involves running and stabilizing the tests in all supported browsers. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside <rich:message /> located on first tab

by Martin Tomasek (JIRA)

[ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.s... ] Martin Tomasek closed RF-12108. ------------------------------- Verified in version 4.5.0.Alpha3 > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside <rich:message /> located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > <h:selectOneMenu id="nSurfacePercentageOfWholePlayback" value="#{newSurface.percentageOfWholePlayback}"> > <f:selectItems value="#{staticPercentagesItems}"/> > </h:selectOneMenu> > <rich:message for="nSurfacePercentageOfWholePlayback" ajaxRendered="true"/> > Second tab (some code with ajax) > Ex. > <a4j:commandLink styleClass="no-decor" execute="@this" action="#{componentManager.deactivateVertically}"> > <h:graphicImage value="/images/icons/delete.gif" alt="Deactivate Vertically"/> > <a4j:param value="#{dayIndex.index + 1}" assignTo="#{componentManager.verticalDeactivationIndex}"/> > </a4j:commandLink> > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > <h:selectOneMenu id="nSurfacePercentageOfWholePlayback" value="#{newSurface.percentageOfWholePlayback}"> > <f:selectItems value="#{staticPercentagesItems}"/> > </h:selectOneMenu> > <rich:message for="nSurfacePercentageOfWholePlayback" ajaxRendered="false"/> > Second tab (some code with ajax) > Ex. > <a4j:commandLink styleClass="no-decor" execute="@this" action="#{componentManager.deactivateVertically}"> > <h:graphicImage value="/images/icons/delete.gif" alt="Deactivate Vertically"/> > <a4j:param value="#{dayIndex.index + 1}" assignTo="#{componentManager.verticalDeactivationIndex}"/> > </a4j:commandLink> > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (RF-13724) Showcase - leftovers of old Editor skinning setup cause 404 error

by Juraj Húska (JIRA)

[ https://issues.jboss.org/browse/RF-13724?page=com.atlassian.jira.plugin.s... ] Juraj Húska updated RF-13724: ----------------------------- Description: In the example for editor advanced configuration, there is leftover of old skinning setup: {code:xml} <h:form> <a4j:outputPanel style="display:none"> <rich:editor skin="kama" /> <rich:editor skin="v2" /> <rich:editor skin="office2003" /> </a4j:outputPanel> </h:form> {code} This causes 404 HTTP errors, while those skins can not be found in the resources. Note that this errors do not affect any functionality nor they are somehow visible elsewhere than JS console. was: In the example for editor advanced configuration, there is leftover of old skinning setup: {code:xml} <h:form> <a4j:outputPanel style="display:none"> <rich:editor skin="kama" /> <rich:editor skin="v2" /> <rich:editor skin="office2003" /> </a4j:outputPanel> </h:form> {code} This causes 404 HTTP errors, while those skins can not be found in the resources. > Showcase - leftovers of old Editor skinning setup cause 404 error > ----------------------------------------------------------------- > > Key: RF-13724 > URL: https://issues.jboss.org/browse/RF-13724 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: showcase > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj Húska > Priority: Trivial > > In the example for editor advanced configuration, there is leftover of old skinning setup: > {code:xml} > <h:form> > <a4j:outputPanel style="display:none"> > <rich:editor skin="kama" /> > <rich:editor skin="v2" /> > <rich:editor skin="office2003" /> > </a4j:outputPanel> > </h:form> > {code} > This causes 404 HTTP errors, while those skins can not be found in the resources. > Note that this errors do not affect any functionality nor they are somehow visible elsewhere than JS console. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

richfaces-issues July 2014