[JBoss JIRA] (RF-13792) Rich notify, show shadow not working
by Matej Novotny (JIRA)
Matej Novotny created RF-13792:
----------------------------------
Summary: Rich notify, show shadow not working
Key: RF-13792
URL: https://issues.jboss.org/browse/RF-13792
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: component-validators
Environment:
RichFaces 4.5.0-SNAPSHOT
Metamer 4.5.0-SNAPSHOT
Mojarra 2.2.6-jbossorg-4
JBoss AS 8.1.0.Final
Java(TM) SE Runtime Environment 1.7.0_25-b15 @ Linux
Firefox 31.0 @ Linux x86_64
Reporter: Matej Novotny
When setting rich:notify attribute {{showShadow=true}} the component does not render at all.
This can be reproduced with both - Metamer and Showcase. Please see steps to reproduce for more details.
We already ahve this covered with a [test|https://github.com/richfaces/richfaces-qa/blob/master/metamer/ftest/...].
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (RF-13780) Random JavaScript error due to missing attribute 'richfaces.RICH_CONTAINER'
by Michael B (JIRA)
[ https://issues.jboss.org/browse/RF-13780?page=com.atlassian.jira.plugin.s... ]
Michael B edited comment on RF-13780 at 8/20/14 6:05 PM:
---------------------------------------------------------
[~michpetrov] sorry for the wrong accusation then! - FireBug wraps the search trough all JS files...
So the problem can be worked around as we did with limitRender="true" fixed on rich:tree. But the original problem in the combination RF+Mojarra still remains if you omit to do this on every AJAX-request. This has the downside, that if you actually want to have some (valid and visible) components being re-rendered on an AJAX request without specifically adding those IDs to the rendered-attribute everywhere throughout the application, you can't do it anymore. As I mentioned, that leads to other problems...
The source of the problem being located in jsf.js means that this is originally bad handling by Mojarra?! - or is it just something that only happens because RF introduces the possibility of some components being automatically re-rendered after AJAX-Requests (like rich:message/s, a4j:outputPanel etc.)?
Will you be looking into the main issue as well? - maybe in cooperation with the guys from Mojarra? - or do we have to file a bug report at Mojarra - which would mean back to square one...
was (Author: michaelb80):
[~michpetrov] sorry for the wrong accusation then! - FireBug wraps the search trough all JS files...
So the problem can be worked around as we did with limitRender="true" fixed on rich:tree. But the original problem in the combination RF+Mojarra still remains if you omit to do this on every AJAX-request. This has the downside, that if you actually want to have some (valid and visible) components being re-rendered on an AJAX request without specifically adding those IDs to the rendered-attribute everywhere throughout the application, you can't do it anymore. As I mentioned, that leads to other problems...
The source of the problem being located in jsf.js means that this is originally bad handling by Mojarra?! - or is it just something that only happends because RF introduces the possibility of some components being automatically re-rendered after AJAX-Requests (like rich:message/s, a4j:outputPanel etc.)?
Will you be looking into the main issue as well? - maybe in cooperation with the guys from Mojarra? - or do we have to file a bug report at Mojarra - which would mean back to square one...
> Random JavaScript error due to missing attribute 'richfaces.RICH_CONTAINER'
> ---------------------------------------------------------------------------
>
> Key: RF-13780
> URL: https://issues.jboss.org/browse/RF-13780
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component, component-tree
> Affects Versions: 4.3.7
> Environment: RichFaces 4.3.7
> Mojarra 2.1.29
> Java 7 Update 67 (x64)
> Tomcat 7.0.52 (x64)
> Firefox 31
> Reporter: Michael B
>
> First of all: this is a bug report which may be related to RF-13776, since it also originates in the same spot of the JavaScript library of RichFaces.
> Preface:
> The problem is difficult to reproduce systematically, since it only seems to occur in one of n cases of loading one and the same complex xhtml (with exactly the same data from the backing bean).
> The problem is described based on the rich:tree component when clicking on the expand icon of a treeNode which fires a "ToggleEvent".
> Occasionally there is a JavaScript error in the last line of
> {code}
> richfaces.ui.TreeNode.emitToggleEvent = function(nodeId) {
> var node = document.getElementById(nodeId);
> if (!node) {
> return;
> }
> richfaces.$(node).__fireToggleEvent();
> };
> {code}
> When the problem occurs, the expression {code}richfaces.$(node){code} evaluates to 'undefined'.
> Debugging into the function when the problem occurs:
> {code:title=richfaces.$|borderStyle=solid}
> richfaces.$ = function(source) {
> var element = richfaces.getDomElement( source );
> if(element)
> {
> return( element[richfaces.RICH_CONTAINER] || {} )["component"]
> }
> };
> {code}
> While the element is correctly evaluated to the treeNode/treeNodeToggle-source, the expression {code}element[richfaces.RICH_CONTAINER]{code} evaluates to 'undefined'.
> Reloading the page one or more times produces correct results, where the attribute is set.
> To be able to provide a reproducable example of the problem, please provide some information under which circumstances the property may not be set correctly for some components. Please also give us a hint, where to debug into the RF JavaScript code to find the spot where this property is set.
> Although the problem doesn't occur all the time, it happens quite often with the effect of breaking the entire application. So for future versions I would suggest a check if {code}richfaces.$(xyz){code} evalutes to a valid result, before invoking any operations on the result and maybe write a message to the a4j:log in cases where a valid result is expected but not returned.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (RF-13766) Move classes ElementIsFocused and FocusRetriever to build-resources
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/RF-13766?page=com.atlassian.jira.plugin.s... ]
Michal Petrov resolved RF-13766.
--------------------------------
Resolution: Done
Resolved with RF-12950
> Move classes ElementIsFocused and FocusRetriever to build-resources
> -------------------------------------------------------------------
>
> Key: RF-13766
> URL: https://issues.jboss.org/browse/RF-13766
> Project: RichFaces
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: tests - functional
> Affects Versions: 4.5.0.Alpha3
> Reporter: Martin Tomasek
> Assignee: Martin Tomasek
> Fix For: 4.5.0.Beta1
>
> Original Estimate: 15 minutes
> Remaining Estimate: 15 minutes
>
> Move classes ElementIsFocused and FocusRetriever from components/rich/src/test/integration/org/richfaces/components/focus to build/build-resources/src/main/java/org/richfaces/utils.focus package.
> Several showcases tests use these class too. After perform https://issues.jboss.org/browse/RF-12950 showcase tests will be in richfaces repo and they will need use ElementIsFocused and FocusRetriever. Its good to have these two classes in build-resources and not duplicate them.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (RF-13780) Random JavaScript error due to missing attribute 'richfaces.RICH_CONTAINER'
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/RF-13780?page=com.atlassian.jira.plugin.s... ]
Michal Petrov commented on RF-13780:
------------------------------------
{quote}
The source of the problem being located in jsf.js means that this is originally bad handling by Mojarra?! - or is it just something that only happends because RF introduces the possibility of some components being automatically re-rendered after AJAX-Requests (like rich:message/s, a4j:outputPanel etc.)?
{quote}
I'll have to figure that out. I guess the issue is at our end, but maybe we're relying on Mojarra to do something that it doesn't do.
> Random JavaScript error due to missing attribute 'richfaces.RICH_CONTAINER'
> ---------------------------------------------------------------------------
>
> Key: RF-13780
> URL: https://issues.jboss.org/browse/RF-13780
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component, component-tree
> Affects Versions: 4.3.7
> Environment: RichFaces 4.3.7
> Mojarra 2.1.29
> Java 7 Update 67 (x64)
> Tomcat 7.0.52 (x64)
> Firefox 31
> Reporter: Michael B
>
> First of all: this is a bug report which may be related to RF-13776, since it also originates in the same spot of the JavaScript library of RichFaces.
> Preface:
> The problem is difficult to reproduce systematically, since it only seems to occur in one of n cases of loading one and the same complex xhtml (with exactly the same data from the backing bean).
> The problem is described based on the rich:tree component when clicking on the expand icon of a treeNode which fires a "ToggleEvent".
> Occasionally there is a JavaScript error in the last line of
> {code}
> richfaces.ui.TreeNode.emitToggleEvent = function(nodeId) {
> var node = document.getElementById(nodeId);
> if (!node) {
> return;
> }
> richfaces.$(node).__fireToggleEvent();
> };
> {code}
> When the problem occurs, the expression {code}richfaces.$(node){code} evaluates to 'undefined'.
> Debugging into the function when the problem occurs:
> {code:title=richfaces.$|borderStyle=solid}
> richfaces.$ = function(source) {
> var element = richfaces.getDomElement( source );
> if(element)
> {
> return( element[richfaces.RICH_CONTAINER] || {} )["component"]
> }
> };
> {code}
> While the element is correctly evaluated to the treeNode/treeNodeToggle-source, the expression {code}element[richfaces.RICH_CONTAINER]{code} evaluates to 'undefined'.
> Reloading the page one or more times produces correct results, where the attribute is set.
> To be able to provide a reproducable example of the problem, please provide some information under which circumstances the property may not be set correctly for some components. Please also give us a hint, where to debug into the RF JavaScript code to find the spot where this property is set.
> Although the problem doesn't occur all the time, it happens quite often with the effect of breaking the entire application. So for future versions I would suggest a check if {code}richfaces.$(xyz){code} evalutes to a valid result, before invoking any operations on the result and maybe write a message to the a4j:log in cases where a valid result is expected but not returned.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (RF-13785) Component tree is not visited during RenderResponsePhase
by Cody Lerum (JIRA)
[ https://issues.jboss.org/browse/RF-13785?page=com.atlassian.jira.plugin.s... ]
Cody Lerum commented on RF-13785:
---------------------------------
Additionally the render would never have happened because the action completed and returned a string causing a redirect.
Mojarra 2.2.7
> Component tree is not visited during RenderResponsePhase
> --------------------------------------------------------
>
> Key: RF-13785
> URL: https://issues.jboss.org/browse/RF-13785
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.5.0.Alpha3, 4.5.0.Beta1
> Reporter: Juraj Húska
> Assignee: Michal Petrov
> Priority: Blocker
> Fix For: 4.5.0.Beta1
>
>
> Consider please a form with multiple inputs inside {{popupPanel}}, which is configured to hide when there are no validation issues.
> *The issue is:* If the form is submitted e.g. with {{a4j:commandButton}}, then it hides even when there are some validation issues.
> {{PopupPanel}} has set {{oncomplete}} attribute to:
> {code:JavaScript}
> oncomplete="if (!#{facesContext.validationFailed}) { #{rich:component('popup')}.hide(); } "
> {code}
> {{facesContext.validationFailed}} is wrongly evaluated always to {{false}}.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months