[JBoss JIRA] (RF-13062) r:validator stops working
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13062?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13062:
-------------------------------
Fix Version/s: 5.0.0.Alpha2
> r:validator stops working
> -------------------------
>
> Key: RF-13062
> URL: https://issues.jboss.org/browse/RF-13062
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 5.0.0.Alpha1
> Reporter: Juergen Zimmermann
> Assignee: Pavol Pitonak
> Fix For: 5.0.0.Alpha2
>
>
> I just tried r:validator with the current snapshot for WildFly 8.0.0.Alpha2 (changed Mojarra 2.2.0 to 2.1.23). However, if I'm doing a wrong input nothing happens. No error message, no stacktrace, just nothing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (RF-13063) RichFacesInputNumberSlider setValueByDragging
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13063?page=com.atlassian.jira.plugin.s... ]
Brian Leathem reassigned RF-13063:
----------------------------------
Assignee: Pavol Pitonak
[~ppitonak] Can you assess and schedule accordingly?
> RichFacesInputNumberSlider setValueByDragging
> ---------------------------------------------
>
> Key: RF-13063
> URL: https://issues.jboss.org/browse/RF-13063
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: qe
> Affects Versions: 4.3.2
> Reporter: Bernard Labno
> Assignee: Pavol Pitonak
> Priority: Minor
>
> In richfaces-qa/page-fragments there is RichFacesInputNumberSlider fragment. It would be great to be able to test setting value as percentage of width implemented as dragging the handle.
> One can do it like that:
> {code}
> ((JavascriptExecutor) GrapheneContext.getProxy()).executeScript("arguments[0].scrollIntoView(true);", weightSlider.getNumberSlider().getRoot());
> waitGui();
> final int width = weightSlider.getNumberSlider().getWidth();
> final int where = (int) (width * percentage);
> final WebElement handle = weightSlider.getNumberSlider().getHandleElement();
> final Action action = new Actions(GrapheneContext.getProxy()).clickAndHold(handle)
> .moveToElement(weightSlider.getNumberSlider().getRoot(), where, 0)
> .release(handle)
> .build();
> {code}
> It is very important to bring component into view before dragging.
> If you do not do that and component is very far to the right (you need to scroll to the right to see it) then calculations are wrong.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (RF-13063) RichFacesInputNumberSlider setValueByDragging
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13063?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13063:
-------------------------------
Description:
In richfaces-qa/page-fragments there is RichFacesInputNumberSlider fragment. It would be great to be able to test setting value as percentage of width implemented as dragging the handle.
One can do it like that:
{code}
((JavascriptExecutor) GrapheneContext.getProxy()).executeScript("arguments[0].scrollIntoView(true);", weightSlider.getNumberSlider().getRoot());
waitGui();
final int width = weightSlider.getNumberSlider().getWidth();
final int where = (int) (width * percentage);
final WebElement handle = weightSlider.getNumberSlider().getHandleElement();
final Action action = new Actions(GrapheneContext.getProxy()).clickAndHold(handle)
.moveToElement(weightSlider.getNumberSlider().getRoot(), where, 0)
.release(handle)
.build();
{code}
It is very important to bring component into view before dragging.
If you do not do that and component is very far to the right (you need to scroll to the right to see it) then calculations are wrong.
was:
In richfaces-qa/page-fragments there is RichFacesInputNumberSlider fragment. It would be great to be able to test setting value as percentage of width implemented as dragging the handle.
One can do it like that:
((JavascriptExecutor) GrapheneContext.getProxy()).executeScript("arguments[0].scrollIntoView(true);", weightSlider.getNumberSlider().getRoot());
waitGui();
final int width = weightSlider.getNumberSlider().getWidth();
final int where = (int) (width * percentage);
final WebElement handle = weightSlider.getNumberSlider().getHandleElement();
final Action action = new Actions(GrapheneContext.getProxy()).clickAndHold(handle)
.moveToElement(weightSlider.getNumberSlider().getRoot(), where, 0)
.release(handle)
.build();
It is very important to bring component into view before dragging.
If you do not do that and component is very far to the right (you need to scroll to the right to see it) then calculations are wrong.
> RichFacesInputNumberSlider setValueByDragging
> ---------------------------------------------
>
> Key: RF-13063
> URL: https://issues.jboss.org/browse/RF-13063
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: qe
> Affects Versions: 4.3.2
> Reporter: Bernard Labno
> Priority: Minor
>
> In richfaces-qa/page-fragments there is RichFacesInputNumberSlider fragment. It would be great to be able to test setting value as percentage of width implemented as dragging the handle.
> One can do it like that:
> {code}
> ((JavascriptExecutor) GrapheneContext.getProxy()).executeScript("arguments[0].scrollIntoView(true);", weightSlider.getNumberSlider().getRoot());
> waitGui();
> final int width = weightSlider.getNumberSlider().getWidth();
> final int where = (int) (width * percentage);
> final WebElement handle = weightSlider.getNumberSlider().getHandleElement();
> final Action action = new Actions(GrapheneContext.getProxy()).clickAndHold(handle)
> .moveToElement(weightSlider.getNumberSlider().getRoot(), where, 0)
> .release(handle)
> .build();
> {code}
> It is very important to bring component into view before dragging.
> If you do not do that and component is very far to the right (you need to scroll to the right to see it) then calculations are wrong.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (RF-13066) a4j:ajax does not work with tomahawk radiobuttons
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13066?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13066:
-------------------------------
Fix Version/s: 5-Tracking
> a4j:ajax does not work with tomahawk radiobuttons
> -------------------------------------------------
>
> Key: RF-13066
> URL: https://issues.jboss.org/browse/RF-13066
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.0.Final
> Environment: a4j:ajax does not work inside a tomahawk radiobutton
> Reporter: Andrea Martino
> Labels: a4j:ajax
> Fix For: 5-Tracking
>
>
> for example the following code does not work:
> {code}
> <t:selectOneRadio id="myRadio" value="#{testtest.xxxEnum}" layout="spread">
> <s:enumItem enumValue="XXX" label="XXX" />
> <s:enumItem enumValue="YYY" label="YYY" />
> <a4j:ajax />
> </t:selectOneRadio>
> <div class="ct-radio">
> <strong><t:radio for="myRadio" index="0"/></strong>
> </div>
> <div class="ct-radio">
> <strong><t:radio for="myRadio" index="1"/></strong>
> </div>
> {code}
> If I replace <a4j:ajax/> by <f:ajax/> everything works as expected. I would like to user a4j:ajax instead of f:ajax because tooltips are not correctly refreshed when I use f:ajax (there should be already a bug opened for that).
> PS: I'm using tomahawk 1.1.14
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (RF-13071) Undeploying Showcase from Tomcat6/7 can cause memory leak
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13071?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13071:
------------------------------------
Thanks Juraj. The showcase will get a refit in Alpha2/Alpha3. We'll see if this continues to be an issue after that.
> Undeploying Showcase from Tomcat6/7 can cause memory leak
> ---------------------------------------------------------
>
> Key: RF-13071
> URL: https://issues.jboss.org/browse/RF-13071
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-push/poll, showcase
> Affects Versions: 4.1.0.Final, 5.0.0.Alpha1
> Reporter: Juraj Húska
> Priority: Minor
> Labels: memory_leak, performance
> Fix For: 5-Tracking
>
>
> When undeploying showcase from Tomcat 6/7 then following log is present on the server console:
> {code}
> SEVERE: The web application [/richfaces-showcase-tomcat6] appears to have started a thread named [Thread-0 (group:HornetQ-client-factory-threads-1831192424-1080990297)] but has failed to stop it. This is very likely to create a memory leak.
> {code}
> There is lot of such logs, just the _Thread-counter_ is changing.
> * 11 such logs just with showcase deploying and then right after undeploying
> * bit more when after deploying playing a little bit with {{r:push}}
> IMHO it is not just warning. I am experiencing {{Out of Memory}} issues when testing on Tomcat. I need to use quite big {{Perm Gen}} and {{Heap size}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months