[JBoss JIRA] (RF-13721) dataTable: columnClasses attribute doesn't work as described
by Michal Petrov (JIRA)
Michal Petrov created RF-13721:
----------------------------------
Summary: 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: 5.0.0.Alpha3, 4.5.0.Alpha2, 4.3.7
Reporter: Michal Petrov
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, 2 months
[JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.s... ]
Matej Novotny updated RF-13711:
-------------------------------
Steps to Reproduce:
* Start Wildfly
* Deploy Metamer
* Go to [this page|http://localhost:8080/metamer/faces/components/a4jAjax/rf-13711.xhtml]
* Open browser console
* Click the button
** Expected: Three lines appear in the console:
*** {{start}} //triggered by a4j:status
*** {{POST...}} //request itself
*** {{stop}} //triggered by a4j:status
** Actual: Only request itself is displayed in console
was:
* Start JBossAS 7.1 (or for RF 4.5 Wildfly)
* Deploy Metamer
* Go to [this page|http://localhost:8080/metamer/faces/components/a4jAjax/rf-13711.xhtml]
* Open browser console
* Click the button
** Expected: Three lines appear in the console:
*** {{start}} //triggered by a4j:status
*** {{POST...}} //request itself
*** {{stop}} //triggered by a4j:status
** Actual: Only request itself is displayed in console
> a4j:ajax status does not work as expected
> -----------------------------------------
>
> Key: RF-13711
> URL: https://issues.jboss.org/browse/RF-13711
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.7, 4.3.8
> Environment: IE8, Mozilla Firefox 30
> Reporter: Evgeny Mironenko
> Assignee: Matej Novotny
> Fix For: 4.5-Tracking
>
>
> Status attribute for {{a4j:ajax}} does not work as expected.
> I tried to create simple project with content:
> {code:title=index.xhtml}
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <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:head>
> <h:body>
> <a4j:status id="progress" onstart="console.log('start')"
> onstop="console.log('stop')"/>
> <div id="content">
> <h:form>
> <h:commandButton value="Click">
> <a4j:ajax event="click" status="progress" listener="#{testBean.invoke}"/>
> </h:commandButton>
> </h:form>
> </div>
> </h:body>
> </html>
> {code}
> It did not work for me. I do not see any log messages in the console.
> As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[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:
-----------------------------
Priority: Critical (was: Major)
> 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, 2 months
[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:
-----------------------------
Labels: mobile regression (was: mobile)
> 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, 2 months
[JBoss JIRA] (RF-13720) Mobile Showcase - CSV demo with JS error and does not work
by Juraj Húska (JIRA)
Juraj Húska created RF-13720:
--------------------------------
Summary: 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
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, 2 months
[JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal
by Jonáš Trantina (JIRA)
[ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.s... ]
Jonáš Trantina commented on RF-13719:
-------------------------------------
To reproduce via reproducer.zip, just build and deploy the portlet on JPP. Access the portlet and:
1) click submit button - observe the logs and see form was submitted
2) choose some files and upload them
2.5) see in the DOM that form action url has changed
3) click submit button - form is not submitted well
> 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
> 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, 2 months
[JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal
by Jonáš Trantina (JIRA)
[ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.s... ]
Jonáš Trantina updated RF-13719:
--------------------------------
Attachment: reproducer.zip
> 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
> 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, 2 months
[JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal
by Jonáš Trantina (JIRA)
Jonáš Trantina created RF-13719:
-----------------------------------
Summary: 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
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, 2 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:
------------------------------------
This is great, thanks [~marcelkolsteren]. I'll merge your PR. Would you mind formulating one for RichFaces 4.5 as well:
https://github.com/richfaces/richfaces/tree/4.5.x
> 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, 2 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:
---------------------------------------
Thanks! In order to prevent that the fix for this issue will be broken in the future, I created an extra qunit test. Here is the pull request:
[https://github.com/richfaces4/core/pull/25]
I also fixed the problem that the QUnitTest class executed all test modules in each of the test methods, instead of only the module for which the test method is intended. Each test module was executed many times, which is a waste of test time, and which clutters the test results if a test is failing.
Furthermore, I added the change for stopping the timer.
> 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, 2 months