[JBoss JIRA] (RF-13682) Stateless view: CSS stylesheets not included in head after form submit
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-13682?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak updated RF-13682:
-------------------------------
Labels: (was: needs-qe)
> Stateless view: CSS stylesheets not included in head after form submit
> ----------------------------------------------------------------------
>
> Key: RF-13682
> URL: https://issues.jboss.org/browse/RF-13682
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.7
> Environment: OpenSuse 13.1 x64
> OpenJDK 1.7.0_51
> Apache Tomcat 8.0.8
> JSF: org.glassfish:javax.faces:2.1.28
> Reporter: Tony Cramer
> Assignee: Brian Leathem
> Fix For: 4.5.0.Alpha3
>
> Attachments: rf-demo-skinning.zip, rf-demo-skinning_and_style.zip
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> If view is stateless <f:view transient="true"...
> Issue 1. skinning.css is not included after submitting a form at all.
> Issue 2. Any other stylesheets manually included with h:outputStylesheet are not included in head but in body after submit.
> Maven project reproducing the issue attached.
> Please use "rf-demo-skinning_and_style.zip" - reproduces both issues.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years
[JBoss JIRA] (RF-13568) IllegalArgumentException for PushResource.jsf
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-13568?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak reassigned RF-13568:
----------------------------------
Assignee: Martin Tomasek (was: Jiří Štefek)
> IllegalArgumentException for PushResource.jsf
> ---------------------------------------------
>
> Key: RF-13568
> URL: https://issues.jboss.org/browse/RF-13568
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-push/poll
> Affects Versions: 5.0.0.Alpha3
> Environment: WildFly snapshot with Undertow 1.0.1
> Reporter: Juergen Zimmermann
> Assignee: Martin Tomasek
>
> Im using the latest WildFly snapshot containing Undertow 1.0.1. I'm getting tons of stacktraces like the following:
> {code}
> [io.undertow.request] UT005023: Exception handling request to /shop/rfRes/org.richfaces.ui.ajax.push.PushResource.jsf: java.lang.IllegalArgumentException: pushTopic request parameter must be present
> at org.richfaces.ui.ajax.push.PushResource.encode(PushResource.java:87) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3]
> at org.richfaces.resource.UserResourceWrapperImpl.encode(UserResourceWrapperImpl.java:187) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3]
> at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:229) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:643) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years
[JBoss JIRA] (RF-13715) <rich:tooltip> not working inside <rich:tab> header facet
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-13715?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak reassigned RF-13715:
----------------------------------
Assignee: Martin Tomasek (was: Pavol Pitonak)
> <rich:tooltip> not working inside <rich:tab> header facet
> ---------------------------------------------------------
>
> Key: RF-13715
> URL: https://issues.jboss.org/browse/RF-13715
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-output
> Affects Versions: 4.3.7
> Environment: Firefox 26, Chromium 31, Opera 12.16
> Reporter: Martin Höller
> Assignee: Martin Tomasek
> Labels: tooltip
>
> A tooltip doesn't show up, when it's used in a header-facet of a <rich:tab> component. The following code demonstrates the problem:
> {code:xml}
> <rich:tabPanel>
> <rich:tab>
> <f:facet name="header">
> <h:panelGroup id="foo">
> myTab
> <rich:tooltip>
> some tooltip
> </rich:tooltip>
> </h:panelGroup>
> </f:facet>
> tab content
> </rich:tab>
> </rich:tabPanel>
> {code}
> The same tooltip works in the tab's content.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years
[JBoss JIRA] (RF-11782) [rich:tabPanel] switching tabs doesn't work correctly with switchtype="ajax"
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-11782?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak commented on RF-11782:
------------------------------------
# deploy Metamer and open http://localhost:8080/metamer/faces/components/richTabPanel/lazyLoading.x...
# check the list of JSF phases at the top of page - there is getTestListA, getTestListB - none of these should be there
# switch to tab2 - getTestListA should be in list, nothing is there
# switch to tab3 - getTestListB should be in list, getTestListA is there
# switch to tab1 - nothing should be in list, getTestListA and getTestListB are there
> [rich:tabPanel] switching tabs doesn't work correctly with switchtype="ajax"
> ----------------------------------------------------------------------------
>
> Key: RF-11782
> URL: https://issues.jboss.org/browse/RF-11782
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-panels-layout-themes
> Affects Versions: 4.1.0.CR1
> Environment: mojarra-2.1.4, RF-CR1
> Reporter: Rene O
> Assignee: Brian Leathem
> Labels: lazy-loaded
> Fix For: 5-Tracking
>
> Attachments: jsf2testcase.war
>
>
> A testcase to reproduce this issue is attached:
> http://localhost:8080/jsf2testcase/tabswitchtest.jsf
> Steps to reproduce the issue:
> 1. switch to 'Tab 3' -> console/server-log shows 'getTestListA' and 'getTestListB' -> this is a bug, expected is only 'getTestListB', because tab3 has only one table with testListB
> 2. switch to 'Tab 1' -> console/server-log shows 'getTestListB' -> this is a bug, expected is nothing new in console/server-log, because tab1 has no table
> {code:title=xhtml}
> ...
> <h:form id="testform">
> <rich:tabPanel id="tabpanel" switchType="ajax" activeItem="#{dataBean.activeTab}">
> <rich:tab id="tab1" header="Tab 1">
> Here is tab #1
> </rich:tab>
> <rich:tab id="tab2" header="Tab 2">
> <rich:dataTable value="#{dataBean.testListA}" var="item" rows="10">
> <rich:column >
> <f:facet name="header">
> List A
> </f:facet>
> <h:outputText value="#{item.a}"/>
> </rich:column>
> </rich:dataTable>
> </rich:tab>
> <rich:tab id="tab3" header="Tab 3">
> <rich:dataTable value="#{dataBean.testListB}" var="item" rows="10">
> <rich:column >
> <f:facet name="header">
> List B
> </f:facet>
> <h:outputText value="#{item.a}"/>
> </rich:column>
> </rich:dataTable>
> </rich:tab>
> </rich:tabPanel>
> </h:form>
> ...
> {code}
> {code:title=java}
> ...
> public List<TestObject> getTestListA() {
> System.out.println("getTestListA");
> return testListA;
> }
> ...
> public List<TestObject> getTestListB() {
> System.out.println("getTestListB");
> return testListB;
> }
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years
[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:
---------------------------------------
When investigating the unit test problems, I found a potential problem in the code. This line removes an element from the queue:
{noformat}
items.shift;
{noformat}
So the request delay timer is not stopped for entries that are removed from the queue. I propose to replace that line with:
{noformat}
var removedEntry = items.shift();
removedEntry.stopTimer();
{noformat}
When the timer is not stopped, the callback onRequestDelayPassed will be called on removed entries that still have a running timer. That doesn't seem to do much harm, but still it's better to fix this.
> 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
[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:
---------------------------------------
I'm afraid that the extra _readyToSubmit_ check breaks my solution. The requestDelay determines how long an entry should stay at the end of the queue, waiting to be combined with similar requests. If we're removing stale entries from the queue, and we encounter the last entry in the queue which is still waiting to get combined, we should remove it from the queue if it is stale. Otherwise it will cause problems at the time it's actually submitted.
As Pavol said, I developed the fix for the 4.3 version, and there the unit test ran fine. Today I merged my original patch to the 4.5 version, and the unit test failed over there. But the root cause had nothing to do with my original fix, but with the fact that the _richfaces_ variable has been renamed to _rf_ in 4.5, so that _richfaces.getDomElement_ does not work any more. Changing it to _rf.getDomElement_ fixed the unit test.
> 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
[JBoss JIRA] (RF-13715) <rich:tooltip> not working inside <rich:tab> header facet
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13715?page=com.atlassian.jira.plugin.s... ]
Brian Leathem reassigned RF-13715:
----------------------------------
Assignee: Pavol Pitonak
This is likely a CSS issue. QE please provide a metamer sample that can be used for analysis.
> <rich:tooltip> not working inside <rich:tab> header facet
> ---------------------------------------------------------
>
> Key: RF-13715
> URL: https://issues.jboss.org/browse/RF-13715
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-output
> Affects Versions: 4.3.7
> Environment: Firefox 26, Chromium 31, Opera 12.16
> Reporter: Martin Höller
> Assignee: Pavol Pitonak
> Labels: tooltip
>
> A tooltip doesn't show up, when it's used in a header-facet of a <rich:tab> component. The following code demonstrates the problem:
> {code:xml}
> <rich:tabPanel>
> <rich:tab>
> <f:facet name="header">
> <h:panelGroup id="foo">
> myTab
> <rich:tooltip>
> some tooltip
> </rich:tooltip>
> </h:panelGroup>
> </f:facet>
> tab content
> </rich:tab>
> </rich:tabPanel>
> {code}
> The same tooltip works in the tab's content.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years
[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 commented on RF-13714:
------------------------------------
Thanks for sharing your use case. That makes the issue more clear.
> 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
> Labels: dropDownMenu, tabPanel
> Fix For: 4.5-Tracking
>
> Attachments: tabPanel.png
>
>
> 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)
10 years
[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 updated RF-13714:
-------------------------------
Issue Type: Feature Request (was: Bug)
> DropDownMenu not working inside tab-header
> ------------------------------------------
>
> Key: RF-13714
> URL: https://issues.jboss.org/browse/RF-13714
> Project: RichFaces
> Issue Type: Feature Request
> 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
> Labels: dropDownMenu, tabPanel
> Fix For: 4.5-Tracking
>
> Attachments: tabPanel.png
>
>
> 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)
10 years