2 Replies Latest reply on May 13, 2014 11:23 AM by Brian Leathem

    [RF 4.3.5.Final] contextMenu for extendedDataTable breaks after ajax render of contextMenu

    gmlussi Newbie

      I'm pretty sure I've found a new bug introduced in release 4.3.5.Final, so I'm hoping somebody can either prove me wrong and help me find a fix, or we get it raised officially...


      Basically, 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:


      Cannot call method 'show' of null in menu-base.js (at line 108 there is a call to this.popup, but popup is null)


      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:




      <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"


      <html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html" xmlns:rich="http://richfaces.org/rich">



          <h:form id="testForm">


                  <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:contextMenu id="contextMenu1" target="table1">

                          <rich:menuItem render="table1,contextMenu1" mode="ajax"

                                        actionListener="#{testBean.addItem}">Context Menu 1 Item</rich:menuItem>



                  <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:contextMenu id="contextMenu2" target="table2">

                          <rich:menuItem render="table2,contextMenu2" mode="ajax"

                                        actionListener="#{testBean.addItem}">Context Menu 2 Item</rich:menuItem>









      And a simple test bean:



      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;



      public class TestBean implements Serializable {

           List<String> items = new ArrayList<>(); 

          public TestBean() {





          public void addItem(){



           public List<String> getItems() {

                return items;





      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):https://issues.jboss.org/i#browse/RF-11973


      Does anybody have any suggestions or insights into this, or do you think it should be raised as a bug?


      This issue is preventing us from upgrading to 4.3.5, which is a vital upgrade for us to fix a critical memory leak due to the use of richfaces push / the atmosphere framework (4.3.5 updated the Atmosphere version, which stopped our inactive HttpSessions piling up), so any help would be much appreciated.


      Thanks, Gavin.