[
https://issues.jboss.org/browse/RF-13645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971016#comment-12971016
]
Brian Leathem edited comment on RF-13645 at 5/27/14 6:00 PM:
-------------------------------------------------------------
QE: Please verify this potential regression.
was (Author: bleathem):
Please verify this potential regression.
> contextMenu for extendedDataTable breaks after ajax render of contextMenu
> -------------------------------------------------------------------------
>
> Key: RF-13645
> URL: https://issues.jboss.org/browse/RF-13645
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-menu
> Affects Versions: 4.3.5, 4.3.6
> Environment: WIN7 / JBOSS AS 7.1.1
> Reporter: Steffen Michel
> Assignee: Pavol Pitonak
> Priority: Blocker
>
> Anything that causes an ajax re-render of a contextMenu which is attached to
> an extendedDataTable causes the contextMenu to subsequently be broken,
> triggering a JavaScript error instead of displaying the menu. The error seems
> to be this:
> {quote}
> Cannot call method 'show' of null in menu-base.js (at line 108 there is a
> call to this.popup, but popup is null)
> {quote}
> The reason I need to ajax re-render the context menu is because in my
> situtation it's held within a tab panel, and if it doesn't get re-rendered
> then it stops working after switching tabs using ajax mode (though it also
> breaks if the contextMenu is held outside of the tab panel, so that isn't a
> potential solution).
>
> I created a stripped down example of my specific situation, with two extended
> data tables, each held in a different tab within a tab panel, and one context
> menu for each table. Changing tabs will cause the context menu to break
> without it explicitly being called in a render list. The same kind of break
> occurs if the contextMenu is called as part of any ajax render list:
> {code}
> <!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:rich="http://richfaces.org/rich";>
> <h:head></h:head>
> <h:body>
> <h:form id="testForm">
> <rich:tabPanel>
> <rich:tab id="tab1" header="Tab 1">
> <rich:extendedDataTable value="#{testBean.items}"
> var="beanVar" id="table1">
> <rich:column id="col1">
> <h:outputText value="#{beanVar}"/>
> </rich:column>
> </rich:extendedDataTable>
> <rich:contextMenu id="contextMenu1" target="table1">
> <rich:menuItem render="table1,contextMenu1" mode="ajax"
>
> actionListener="#{testBean.addItem}">Context Menu 1 Item</rich:menuItem>
> </rich:contextMenu>
> </rich:tab>
> <rich:tab id="tab2" header="Tab 2">
> <rich:extendedDataTable value="#{testBean.items}"
> var="beanVar2" id="table2">
> <rich:column id="col2">
> <h:outputText value="#{beanVar2}"/>
> </rich:column>
> </rich:extendedDataTable>
> <rich:contextMenu id="contextMenu2" target="table2">
> <rich:menuItem render="table2,contextMenu2" mode="ajax"
>
> actionListener="#{testBean.addItem}">Context Menu 2 Item</rich:menuItem>
> </rich:contextMenu>
> </rich:tab>
> </rich:tabPanel>
> </h:form>
> </h:body>
> </html>
> {code}
> And a simple test bean:
> {code}
> import
> org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ViewAccessScoped;
>
> import javax.inject.Named;
> import java.io.Serializable;
> import java.util.ArrayList;import java.util.List;
> @Named
> @ViewAccessScoped
> public class TestBean implements Serializable {
> List<String> items = new ArrayList<>();
> public TestBean() {
> items.add("one");
> items.add("two");
> items.add("three");
> }
> public void addItem(){
> items.add("another");
> }
> public List<String> getItems() {
> return items;
> }
> }
> {code}
> The above test situation works fine in richfaces 4.3.1, 4.3.2, 4.3.3 and
> 4.3.4, but breaks when upgraded to 4.3.5.Final.
>
>
> There was a different bug fixed in 4.3.5 which seems highly related to this,
> but opposite, making me wonder if whatever was done there caused this bug
> instead (but it's just a guess): RF-11973
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
_______________________________________________
richfaces-issues mailing list
richfaces-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/richfaces-issues
